Bitcraze Forums

Posted: **Fri Oct 21, 2016 3:28 pm**

I am working on characterizing the power consumed by various parts of the system. I am power the CF2 from a power supply with a shunt resistor going into the battery terminal. And then I am reading the current and voltage using labview to get the consumed power during various states.

1. Power consumed at idle with radio connection. I flashed the normal firmwares on the CF2 and used the python api to set a setpoint of {0,0,0,0} so it would be transmitting (repeated over 30 seconds), but would not be using power for the motors.

avg power: 0.2649 W

2. Same setup as above but with the crazyradio PA removed from the computer so there could be no radio packets sent.

avg power: 0.2545 W

So this is about 10 W less than using the radio. This is about expected.

3. I changed the STM32 bootloader to not boot the firmware (so just commented out that complete section involving bootpin and reflashed the bootloader). I also removed the LEDs to further decrease the power. At this point when powered on the only thing running is the NRF51 (I assume).

avg power: 0.2183 W.

My question:

Is 218 mW of power really being consumed by the NRF51 during idle state (no radio packets, no STM32 firmware running)? This indicates the STM32 firmware during idle is consuming around 37mW of power.

Do these values (218 vs 37 mW) seem accurate? I can provide the data or run any other power tests you want.

Posted: **Mon Oct 24, 2016 1:44 pm**

That is really interesting figures as we never had the time to investigate the power consumption in detail.

My first thought is that it is the power amplifier (PA) that consumes in idle state, listening on radio. The PA can be disabled. It will limit the range a lot (~50db attenuation) but would be interesting to test.

Do these values (218 vs 37 mW) seem accurate? I can provide the data or run any other power tests you want.

I would expect the STM32 and IMU consume most of the power so the figures look a bit strange indeed. You can prevent the STM32 and IMU from starting by not enabling the VCC power.

Are you able to share what you try to accomplish? Then it would be easier to point you in the right direction but totally understand if you can't.

Posted: **Tue Oct 25, 2016 3:14 pm**

Thanks for the help! I am working to build a blimp powered with a solar panel. I need to get the electronics power consumption down so it has enough power for the motors. The first step was characterizing the power.

I changed the firmware with the two modifications.

With NRF51 firmware, with the Power Amplifier, WITHOUT STM32 firmware.

100mW

With NRF51 firmware, without the PA, without STM32 firmware.

~25mW

The issue is now flashing the NRF51 firmware. I was able to flash the various versions of the NRF51 firmware using the CLOAD tool. At some point during all the modifications something broke. I attempted to flash the firmware using the debugger and something broke.

The system only powers on when the battery is connected. Hitting the power button does nothing when off, and when on it only turns it off. It refuses to enter bootloader mode by holding the power button.

I am able to flash the STM Firmware and STM bootloader using the 'make flash'.

When I try to flash the NRF firmware I get the following error:

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.890459
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x0bb11477
in procedure 'init'
in procedure 'ocd_bouncer'

Makefile:116: recipe for target 'flash' failed
make: *** [flash] Error 1

I am not sure why it works to flash the two other programs on the STM but not onto the NRF.

Posted: **Wed Oct 26, 2016 1:43 am**

Just as a sanity check: Do you use the JTAG connector for the NRF (see https://wiki.bitcraze.io/projects:crazy ... pter:index)?

Posted: **Wed Oct 26, 2016 8:42 am**

From the debug adapter I am using the 6 pin cable (black with one white) coming from the Crazyflie2.0 SWV port. The crazyfly debug adapter is connected to the STM32 Discovery.

This black and white cable goes into the matching port on the Crazyflie2.0. In the debug instructions it says it's for "Connect to Crazyflie 2.0 for nRF51 or STM32F4 debugging".

Should I be using the specific NRF51 debug port? That seems redundant considering the main port is for both.

I used openocd and gdb to flash the compiled elf files onto the board.

1. I started the openocd connection using "make openocd" in the crazyflie-firmware folder.
2. I compiled the nrf mbs, then nrf bootloader, then nrf firmware, then stm bootloader, then stm firmware
3. I then used arm-none-eabi-gdb to load each of the elf files onto the board. ("tar ext :3333" then "load")

All of them loaded without error, but the CF2 still does not work as expected. When I connect the battery it goes through the normal startup routine (lights, noise, etc.)

I can then connect via the radio and control the CF2 using the python client. What I can not do is enter bootloader mode.

When I hit the power button it turns off - and then selecting it again does nothing.

I am unable to enter bootloader mode and I am unable to turn on the CF2 unless I unplug and reconnect the battery.

Something is wrong with one of the bootloaders I think. The only change from stock that is currently running is disable the PA and some minor changes in the STM firmware.

Posted: **Wed Oct 26, 2016 9:08 am**

With NRF51 firmware, with the Power Amplifier, WITHOUT STM32 firmware.

100mW

With NRF51 firmware, without the PA, without STM32 firmware.

~25mW

Should I interpret -25mW as 100 - 25 = 75mW? Those figures look quite right though.

Should I be using the specific NRF51 debug port? That seems redundant considering the main port is for both.

On the debug adapter no. The NRF51 debug port is there to be able to flash the nRF51 without soldering the small adapter board on the CF2 (that is tricky though).

As for nor being able to flash nRF51 anymore, could be a reset problem. Put reset selection on the debug adapter to SWDIO, hold the reset button while starting to flash and then release it. Also try with a battery connected. The USB current limits to 100mA during startup until the charger chip is configured which can be a problem.

Try also to flash back everything with "make factory_reset" in the nRF51 folder.

Posted: **Wed Oct 26, 2016 12:32 pm**

It's a ~ no a -, so it's about 25mW for the NRF firmware without the power amplifier. And 100mW with the NRF firmware with the Power Amplifier.

So the Power Amplifier draws 75 mW.

The reset button does not work. I tried the NRF MSB, bootloader, and firmware and nothing can be flashed using "make flash" no matter the state of the reset button.

I changed the jumper position and tested the reset button and nothing flashes.

This is still the result of nrf image flashing:

openocd -d2 -f interface/stlink-v2.cfg -f target/nrf51_stlink.tcl -c init -c targets -c "reset halt" \
-c "flash write_image erase cf2_nrf.hex" -c "verify_image cf2_nrf.hex" \
-c "reset run" -c shutdown
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
WARNING: target/nrf51_stlink.cfg is deprecated, please switch to target/nrf51.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.891873
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x0bb11477
in procedure 'init'
in procedure 'ocd_bouncer'

Makefile:116: recipe for target 'flash' failed
make: *** [flash] Error 1

The STM bootloader and firmware can be flashed using the debugger. And the system actually kind of works (radio contact) after flashing the 5 different images using GDB. But the power button does nothing except turn off the drone - no ON and no bootloader.

Posted: **Wed Oct 26, 2016 3:36 pm**

Very strange that it doesn't manage to connect to the target. Did you try the "make factory_reset" command?

Posted: **Wed Oct 26, 2016 3:44 pm**

Yes. I tried that option. Ever single "make *" option in any of the free NRF firmwares gives the same issue.

kevin@kevin-ESPRIMO-P956 ~/blimp/crazyflie2-nrf-firmware $ make factory_reset
make mass_erase
make[1]: Entering directory '/home/kevin/blimp/crazyflie2-nrf-firmware'
openocd -d2 -f interface/stlink-v2.cfg -f target/nrf51_stlink.tcl -c init -c targets -c "reset halt" \
-c "nrf51 mass_erase" -c shutdown
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
WARNING: target/nrf51_stlink.cfg is deprecated, please switch to target/nrf51.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.890171
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x0bb11477
in procedure 'init'
in procedure 'ocd_bouncer'

Makefile:140: recipe for target 'mass_erase' failed
make[1]: *** [mass_erase] Error 1
make[1]: Leaving directory '/home/kevin/blimp/crazyflie2-nrf-firmware'
Makefile:169: recipe for target 'factory_reset' failed
make: *** [factory_reset] Error 2

Either it gives the idcode error, or it gives an error saying it can't connect.

I'm just confused since I can flash the firmware using GBD and OpenOCD, but the bootloader mode does not work, and the power button does not work.

Could it be the specific debugger I am using?

Posted: **Wed Oct 26, 2016 4:28 pm**

I went into the openocd config files and changed the device id to match the expected device value.

Now I am getting somewhere. But there seems to be a protected bit set that nothing can erase.

kevin@kevin-ESPRIMO-P956 ~/blimp/crazyflie2-nrf-mbs $ make reset
openocd -d2 -f interface/stlink-v2.cfg -f target/nrf51_stlink.tcl -c init -c targets -c "mww 0x40000544 0x01" -c reset -c shutdown
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
WARNING: target/nrf51_stlink.cfg is deprecated, please switch to target/nrf51.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.888758
Info : nrf51.cpu: hardware has 6 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* nrf51.cpu hla_target little nrf51.cpu reset
shutdown command invoked

kevin@kevin-ESPRIMO-P956 ~/blimp/crazyflie2-nrf-mbs $ make flash
openocd -d2 -f interface/stlink-v2.cfg -f target/nrf51_stlink.tcl -c init -c targets -c "reset halt" \
-c "flash write_image erase nrf_mbs.hex" -c "verify_image nrf_mbs.hex" -c "reset halt" \
-c "mww 0x4001e504 0x01" -c "mww 0x10001014 0x3F000" -c "reset run" -c shutdown
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
WARNING: target/nrf51_stlink.cfg is deprecated, please switch to target/nrf51.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.888758
Info : nrf51.cpu: hardware has 6 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* nrf51.cpu hla_target little nrf51.cpu reset
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002bc msp: 0x20005000
auto erase enabled
Warn : Unknown device (HWID 0x0000a10b)
Warn : Adding extra erase range, 00000000 to 0x0003efff
Error: Cannot erase protected sector at 0x0
Error: failed erasing sectors 0 to 0

Makefile:56: recipe for target 'flash' failed
make: *** [flash] Error 1

So the reset claims it works when I am in the mbs directory.

I also went ahead and did it manually using openocd and telnet in two different terminals

Code: Select all

make openocd
telnet 127.0.0.1 4444

> reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080002bc msp: 0x20005000
> nrf51 mass_erase
Failed to enable erase operation
Failed to erase reg: 0x4001e50c val: 0x00000001
Failed to erase the chip
Couldn't read code region 0 size[FICR]
in procedure 'nrf51'
> flash banks
#0 : nrf51.flash (nrf51) at 0x00000000, size 0xd2b79c00, buswidth 1, chipwidth 1
#1 : nrf51.uicr (nrf51) at 0x10001000, size 0x00000000, buswidth 1, chipwidth 1
> flash write_image erase cf2_nrf.hex
auto erase enabled
Adding extra erase range, 00000000 to 0x00015fff
Cannot erase protected sector at 0x0
failed erasing sectors 0 to 0
in procedure 'nrf51'

There seems to be a write protected bit in sector 0x0 that can not be overwritten.

Is there a nuclear option that will force a reset? Do you have any idea what can be done in this state?

Bitcraze Forums

Power Consumption

Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption

Re: Power Consumption