Serial Connectivity and Serial DFU - High Current Draw - nRF51822

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

Roger Clark — Wed, 07 Sep 2016 22:23:39 GMT

@jpreston

Did you validate the answer

I'm thinking of using Serial DFU, so am interested in knowing what happened.

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

jpreston — Tue, 24 May 2016 14:30:40 GMT

Just to add further information to this problem (we had it crop back up again), the current draw was a result of our host processor waiting to process data received from the nRF51. Since that was still in development, we never reset our internal flag. Hung, your advice regarding using app_uart directly is still valid, so I will now verify this answer.

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

Hung Bui — Mon, 21 Mar 2016 10:05:42 GMT

Hi Jpreston, If you want to use UART to send a byte, I would suggest you to use the app_uart directly, and use an event handler to catch when the byte is sent before closing app uart, instead of using hci slip.

But still I couldn't explain why you have more power consumption when enter SystemOFF mode. Could you try to enter system off right in the bootloader (after you sending the byte) and see what happens ? Would you be able to reproduce the issue with nRF51 DK ?

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

jpreston — Fri, 18 Mar 2016 15:52:20 GMT

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)?

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

jpreston — Fri, 18 Mar 2016 15:16:13 GMT

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.

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

Hung Bui — Fri, 18 Mar 2016 15:04:59 GMT

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.

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

jpreston — Fri, 18 Mar 2016 14:41:35 GMT

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?

RE: Serial Connectivity and Serial DFU - High Current Draw - nRF51822

Hung Bui — Fri, 18 Mar 2016 13:09:23 GMT

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.