Serial Connectivity and Serial DFU - High Current Draw - nRF51822

[jpreston]

I have combined Nordic's serial connectivity code and Nordic's serial DFU example.

Upon initial powerup, the nRF51822 draws an expected amount of current (~600uA). When issuing the system off command via serial, the current draw drops to about 0.5uA, which is to be expected.

The issue occurs when waking the nRF51822 via external interrupt. When I do that, the chip wakes up but starts drawing about 1800uA. Issuing the system off command drops it to about 1200uA. This current draw corresponds to what I see when the debug interface is active (i.e. just after programming the chip without a power cycle).

I have verified that the nRF51 is resetting because I have the DFU code send a string out the UART so the main processor can know it started. I've also verified that the application starts running after waking up from an external interrupt.

I'll also add that I don't see this issue unless I program the bootloader. The Softdevice and connectivity code show expected current draw all the time when the bootloader is not programmed.

Any advice?

[Hung Bui]

Hi jpreston,

I'm suspecting that because the bootloader doesn't reset all the peripheral registers before jumping to application.

I assume you experienced the issue every time you bootup the chip, not only just the first time after the bootloader update the firmware ?

It's very strange to hear that you have 1.2mA when in SystemOFF mode (not just putting CPU to sleep, am I correct ? ) Have you tried to simplify the bootloader so that it won't use any peripheral before jumping to application ?

There could be the chance that the device entered debug mode because of the noise on the SWD pins when starting up, but then it's hard to explain why this doesn't happens if the bootloader is not programmed.

[jpreston]

I think you're right about the bootloader using peripherals before jumping to the application is the problem. I had modified it to send a character out the UART to give our main processor notification that the nRF51 is booting. I'm not positive that this completely solves the issue yet, but I removed that part of the bootloader and it seems to be working properly now. Why do you think this would still cause high current draw when in SystemOFF?

[Hung Bui]

It's strange for me also. By spec, when entering SystemOFF, all peripheral except for wake sources should be turned off. If you enter SystemOFF right in the bootloader, after you printout on UART, and before you jump to application, what would happen ?

You can attach your bootloader and maybe a dummy application that can show the issue, then I can test here on my side and check what could be wrong here.

[jpreston]

The bootloader is slightly modified from the dual_bank_serial_s110 DFU example in SDK 10.0.0. I removed the code that initializes leds and buttons and added these two lines just after GPREGRET is reset:

hci_slip_open();
app_uart_put(0xa5);

When removing those two lines, everything seems to work as expected again. If you have issues getting this to reproduce, I can post the main.c file for the bootloader.

[jpreston]

Upon further inspection, adding a hci_slip_close() fixes the issue as well. However, the character doesn't get transmitted out the UART like it did before. I'm guessing that because the UART is trying to transmit something while the chip is changing context is causing the issue? What would be the best way to accomplish what I'm trying to do here (i.e. transmit character from the bootloader)?