This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Serial Connectivity and Serial DFU - High Current Draw - nRF51822

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?

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related