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

Powering up by using external power the dongle enters DFU mode

Hi to everyone:

 As the title suggest I'm using the NRF52840 PCA10059 dongle and everything works as expected.

The issue comes that I've modified the dongle to instead of drawing power from the USB connector, to use power derived from other board. To do this I've modified as per documentation the necessary jumpers, and provid power through the VDD Out pin. So far so good, I have the board externally powered up and still can use the USB connector to DFU program it.

The issue comes with the powering up sequence:

When powering up, (independently if something is connected to the USB connector) the board goes into DFU mode even when flashed with a valid firmware. I need to power it off and on several times so that it enters the running program mode.

Any idea in how can I avoid this behavior? It seems relate to some reset sequence by a reset pin is not exposed...

Parents
  • Hi Fconta, 

    If you have a look at the dfu_enter_check() in nrf_bootloader.c you can find the list of reasons the dongle would enter DFU mode: 

    If you have uploaded the app via DFU mode then it should pass the first check. 

    I suspect that the dongle entered DFU mode because either the check number 2 or check number 3. 

    Note that on the dongle pin P0.19, P0.21,P0.23, P0.25 are all connected to the reset pin P0.18. If any of these pin turned low it may trigger a pin reset and put the dongle to DFU mode. Also check if you have P1.02 connected to something or not. It's the NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 34 by default. 

    It's a bit difficult to debug the bootloader on the dongle if you don't have the debugger connected to it. So you can either solder a header on P1 port to connect a debugger to it, or you can try to simulate the same hardware on a PCA10056 and can reproduce the issue on the PCA10056 to debug.

Reply
  • Hi Fconta, 

    If you have a look at the dfu_enter_check() in nrf_bootloader.c you can find the list of reasons the dongle would enter DFU mode: 

    If you have uploaded the app via DFU mode then it should pass the first check. 

    I suspect that the dongle entered DFU mode because either the check number 2 or check number 3. 

    Note that on the dongle pin P0.19, P0.21,P0.23, P0.25 are all connected to the reset pin P0.18. If any of these pin turned low it may trigger a pin reset and put the dongle to DFU mode. Also check if you have P1.02 connected to something or not. It's the NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN 34 by default. 

    It's a bit difficult to debug the bootloader on the dongle if you don't have the debugger connected to it. So you can either solder a header on P1 port to connect a debugger to it, or you can try to simulate the same hardware on a PCA10056 and can reproduce the issue on the PCA10056 to debug.

Children
  • Hi:

    Thanks for the input. Just to add a few more information: The only thing connected is an UART device at pins 0.29 and 0.31, nothing else. All other pins are unused. Also, probably not important to the issue, I'm using Zephyr RTOS and uploading the firmware through DFU. All of this works fine and behaves as expected.

    The issue looks like some timing issue between the powering up and the reset line state? Because If I connect the dongle in a "cold" state (disconnected from any power for a few seconds) it enters DFU mode, but if I disconnect it and connect it rapidly if runs the program. As reported nothing is connected to any other pins including the P1.02 pin that is exposed on the back. So maybe the RESET line is held low for too long when powering up externally?

  • Hi Fconta, 

    It's hard to debug without the access the debug interface. I would suggest to try testing the same setup on the PCA10056 or the best is to solder a header on P1. You can get the header from one of the DK. 

  • Hi, thanks for the input.

    It's a bit strage that the issue is within the bootloader and specifically with the pins that where refered, mainly because reset is not exposed, and P0.18, is under the board is also is nothing connected there.

    I'll have a goo and see what I might discover.

Related