Code: Select all
nrf51 mass_erasePower Consumption
Re: Power Consumption
You can try the command
that should erase the full chip and resets all write protection.
Re: Power Consumption
I tried that option. I get this error message
Is the crazyflie dead for good?
The only instance of that error I can find is in the openocd code itself.> 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'
Is the crazyflie dead for good?
Re: Power Consumption
Are you really connected to the nrf51 SWD port on the Crazyflie 2.0 side? Everything is behaving as if you are not talking to the right chip (for example you should never have to change chip ID, chip ID are there to avoid controlling the wrong chip).
On the debuger side there is only one mating connector for the cable. Though, on the crazyflie side you should be connected to a soldered adapter board on the side, not to the connector under the USB port which is only for STM32F405. The two CPUs are not using the same SWD bus since, unfortunately, nRF51 does not support multidrop SWD.
On the debuger side there is only one mating connector for the cable. Though, on the crazyflie side you should be connected to a soldered adapter board on the side, not to the connector under the USB port which is only for STM32F405. The two CPUs are not using the same SWD bus since, unfortunately, nRF51 does not support multidrop SWD.
Re: Power Consumption
So we got it solved - and created a mystery.
The issue we had that after flashing all the code using GBD and openocd, the button would not work and you had reset by power cycling using the battery.
All the issues I had with the device id and the flashing were distraction. I did not need to add th specific nrf debugger onthe CF to fix it.
1. Connect the debugger to the CF
2. "make flash" the STM bootloader
3. "make flash" the CF firmware
4. Enter bootloader mode by holding button and connecting battery. The two LEDs will start blinking. Flash the NRF firmware over the air.
This last step is the puzzling one. I have two folders on my computer with all the code - one (A) is a fresh clone, and one (B) was made a few weeks and slightly modified.
When I used folder A in step four it works. The system restarts and the button functions as expected.
When I used folder B in step four it breaks. The button no longer functions and we can only restart it by pulling the battery.
I checked the git logs and the version of the cfloader is the same and unmodifed. Folder B only has one modification from master - the pm.c. The pm.c in folder B was modified to disable the PA using the define. But this alone does not reproduce the bug. When I disable the PA in folder A and reflash nothing breaks.
There is something specific to the setup in folder B that breaks the button. The Makefiles are the same according to diff. And I purged and reinstalled openocd to make sure there was no configuration difference.
Have you ever encountered this before?
Now that this whole saga is finished I can continue with the power calculations.
The issue we had that after flashing all the code using GBD and openocd, the button would not work and you had reset by power cycling using the battery.
All the issues I had with the device id and the flashing were distraction. I did not need to add th specific nrf debugger onthe CF to fix it.
1. Connect the debugger to the CF
2. "make flash" the STM bootloader
3. "make flash" the CF firmware
4. Enter bootloader mode by holding button and connecting battery. The two LEDs will start blinking. Flash the NRF firmware over the air.
This last step is the puzzling one. I have two folders on my computer with all the code - one (A) is a fresh clone, and one (B) was made a few weeks and slightly modified.
When I used folder A in step four it works. The system restarts and the button functions as expected.
When I used folder B in step four it breaks. The button no longer functions and we can only restart it by pulling the battery.
I checked the git logs and the version of the cfloader is the same and unmodifed. Folder B only has one modification from master - the pm.c. The pm.c in folder B was modified to disable the PA using the define. But this alone does not reproduce the bug. When I disable the PA in folder A and reflash nothing breaks.
There is something specific to the setup in folder B that breaks the button. The Makefiles are the same according to diff. And I purged and reinstalled openocd to make sure there was no configuration difference.
Have you ever encountered this before?
Now that this whole saga is finished I can continue with the power calculations.
Re: Power Consumption
That is a mystery indeed!
When you flash it, you use gdb load command right? Could it be related to this?
From what I read though the nRF51 FW seems effected by flashing the STM32 which is really strange. The nRF51 control all power management...
When you flash it, you use gdb load command right? Could it be related to this?
From what I read though the nRF51 FW seems effected by flashing the STM32 which is really strange. The nRF51 control all power management...
Re: Power Consumption
I have no idea. Yes - we used gdb to load the firmware images.
So running "make clean" in folder B fixes the issue. After OTA flashing it works as expected.
The only thing that I can thing of is the softdevice perhaps. I have not looked to deeply into it, but when I first started playing with the firmware I compiled without BLE and Softdevice to see the power difference. And perhaps one of those linked files remained and got corrupted (?) and later when I would make and flash it was getting compiled in.
That's the only thing that might make sense. I don't know if the softdevice could kill the power button.
So running "make clean" in folder B fixes the issue. After OTA flashing it works as expected.
The only thing that I can thing of is the softdevice perhaps. I have not looked to deeply into it, but when I first started playing with the firmware I compiled without BLE and Softdevice to see the power difference. And perhaps one of those linked files remained and got corrupted (?) and later when I would make and flash it was getting compiled in.
That's the only thing that might make sense. I don't know if the softdevice could kill the power button.
Re: Power Consumption
Final power numbers! There are three different power comparison tests that I ran.
1. Without the STM Firmware:
NRF51 with Power Amplifier: 78mW
NRF51 without Power Amplifier: 17mW
2. With the STM Firmware (power amplifier disabled):
Average idle power 224 mW
Idle maximum power 385 mW
Average idle while connected to radio 343 mW
Maximum idle while connected to radio 785 mW
3. With the STM firmware but toggling the power amplifier
Idle with PA: 260 mW
Idle without PA: 224 mW
We can see that the radio draws about 120 mW during tx/rx even without the PA.
The power amplifier itself draws somewhere around 40 to 60 mWs of power depending on the rest of the system.
The power spikes a lot. Even in idle there would be occasional spikes up to 700mW!
As I mentioned before - we are looking at building a blimp system using a helium balloon but powering the system from solar. The solar panel can supply on the order of 100s of mW (in good conditions) so the actual system power needs to be reduced drastically before it would work. And the motor control tweaked as well to use lower rpm.
1. Without the STM Firmware:
NRF51 with Power Amplifier: 78mW
NRF51 without Power Amplifier: 17mW
2. With the STM Firmware (power amplifier disabled):
Average idle power 224 mW
Idle maximum power 385 mW
Average idle while connected to radio 343 mW
Maximum idle while connected to radio 785 mW
3. With the STM firmware but toggling the power amplifier
Idle with PA: 260 mW
Idle without PA: 224 mW
We can see that the radio draws about 120 mW during tx/rx even without the PA.
The power amplifier itself draws somewhere around 40 to 60 mWs of power depending on the rest of the system.
The power spikes a lot. Even in idle there would be occasional spikes up to 700mW!
As I mentioned before - we are looking at building a blimp system using a helium balloon but powering the system from solar. The solar panel can supply on the order of 100s of mW (in good conditions) so the actual system power needs to be reduced drastically before it would work. And the motor control tweaked as well to use lower rpm.
Re: Power Consumption
It think you are on to it and I think a problem with the nRF51 code could case issues like you seenThat's the only thing that might make sense. I don't know if the softdevice could kill the power button.
That is a great investigation. I'm used to mA numbers so I need to convert it. Since the whole system uses linear regulators the current draw is pretty much proportional to the power draw.
I guess the the high power spikes you see comes from the radio transmission (PA draws ~100mA when TX, 10mA in RX). So minimizing the downlink data will lower the consumption.
The CF2 electronics hasn't been optimized for power consumption so it might be difficult to get those figures really low. It can become very low in sleep mode though (15-20uA) so maybe an option is to have it go on and off. But it all depends what you would like to achieve. If you can share that I will be able to help out better.
Re: Power Consumption
The goal is to get the electronic power consumption as low as possible. I built a blimp using a large helium balloon and we have a flex solar panel to mount on top. The solar panel can provide a few hundred mWs of power.
The major consumption of power in the current CF2 is due to the motors to lift the entire system. Since we don't need much lift from the motors due to the helium, the entire system theoretically could be powered from the solar panel (moving motors really slowly does not use much power)
At the moment the radio power is a secondary concern.
1. I saw that the idle task sleep mode cuts current consumption by 30%. I tested it and it a large effect on the power consumed. You guys are correct.
2. I tried to slow down the entire system by changing the clock frequency and the tick rate frequency. But that breaks the AK8963 self test and locks up a timer.
3. I am no expert in FreeRTOS. Can it be set to turn on and off slowly. Ideally we could just set it run really really slowly. The power consumed is about linear with frequency so cutting the frequency would cut the STM32 power, though not the peripheral power.
4. I set the STM to sleep immediately upon starting and the system is still drawing abut 100mW (about 35mA). So the peripherals are using about 80 mW of power. And the STM is using about a 120mW of power during normal operation. (20 + 80 + 120 = 220 mW which was the normal idle load)
The major consumption of power in the current CF2 is due to the motors to lift the entire system. Since we don't need much lift from the motors due to the helium, the entire system theoretically could be powered from the solar panel (moving motors really slowly does not use much power)
At the moment the radio power is a secondary concern.
1. I saw that the idle task sleep mode cuts current consumption by 30%. I tested it and it a large effect on the power consumed. You guys are correct.
2. I tried to slow down the entire system by changing the clock frequency and the tick rate frequency. But that breaks the AK8963 self test and locks up a timer.
3. I am no expert in FreeRTOS. Can it be set to turn on and off slowly. Ideally we could just set it run really really slowly. The power consumed is about linear with frequency so cutting the frequency would cut the STM32 power, though not the peripheral power.
4. I set the STM to sleep immediately upon starting and the system is still drawing abut 100mW (about 35mA). So the peripherals are using about 80 mW of power. And the STM is using about a 120mW of power during normal operation. (20 + 80 + 120 = 220 mW which was the normal idle load)
Re: Power Consumption
Thanks for info.The goal is to get the electronic power consumption as low as possible. I built a blimp using a large helium balloon and we have a flex solar panel to mount on top. The solar panel can provide a few hundred mWs of power.
I'm not sure the easiest way to lower the consumption but I guess starting with the STM32 is best as it consumes the most. What puzzles me a bit is that it consumes so much in sleep mode. OK, checked the datasheet and it says 59mA @168MHz and all peripherals enabled so that might not be best way to go. Lowering clock is probably best but code isn't made for this so it would have to be adapted. Radio can be optimized by minimizing the downlink data.
That being said I think reaching 100mW (about 27mA) will be difficult. Then I think the system would have to work in an on/off manner but I'm not sure the sensors could handle that.