This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Open Bootloader Stuck in DFU Mode (Nano 33 BLE Issue. DK Is OK)

Good evening,

I’m testing the SDK v17.1.0 “Open Bootloader with DFU” example. I’m using Segger Embedded Studio to program my Nano 33 BLE via the debug interface (P20) of my nRF52840-DK. I’m also programming the Open Bootloader to my DK via its “USB IF MCU” (J2).

nRF52840-DK (As expected)

Everything works as expected… I erase the chip and then program the DK with the Open Bootloader example via the DK’s MCU USB (J2). My Windows PC’s Device Manager lists both the “JLink CDC UART” and the “nRF52 SDFU USB” under Ports. I then use nRF Util to program “blinky” to the DK via its “nRF USB (J3)”.

Blinky now makes the 4 LEDs blink, and SDFU USB disappears from device manager as expected. If I then press the “IF BOOT/RESET” button, the DK goes into DFU mode; its SDFU USB reappears in device manager. No amount of waiting reactivates blinky. Next, I turn the DK off and on via its “SW8 Power” switch. Blinky is then running again.

Nano 33 BLE (Only works at first)

The programming procedure is of course the same as for the DK, i.e., erase the chip, program the bootloader to it, and then use nRF Util to program it with blinky.

Pressing the nano’s button causes it to exit (yellow LED off; SDFU USB disappears from device manager) DFU mode. Releasing the nano’s button causes it to enter DFU mode. This seems to be the reverse of what I was expecting.

Immediately after programming blinky to the nano, blinky runs, but after pressing and releasing the nano’s button or powering it off and on, the nano is then stuck in DFU mode. The only way to get blinky working again is to program it again using nRF Util. Incidentally, DFU mode always works via the nano’s button as described above. The nano's bootloader is only ever erased if I erase the nano's chip via the DK’s debug interface.

After reading “How does the bootloader load the application…”, I decided to trace “nrf_bootloader_app_start()”. It is defined in “nrf_bootloader_app_start.c”, and called from “nrf_bootloader_init(nrf_dfu_observer_t observer)” which itself is defined in “nrf_bootloader.c”.

By commenting nrf_bootloader_app_start(), blinky then never runs which is no surprise, and the bootloader remains functional which is also no surprise.

Please can somebody help me understand how to proceed from here to get the bootloader working as desired for the nano? I’m hoping it’ll perhaps be relatively straightforward, e.g., change certain settings within “sdk_config.h”?

Thank you, Gary.

  • Hi Hung,

    Awesome! it works perfectly.

    Removing CONFIG_GPIO_AS_PINRESET from the preprocessor definitions has fixed the issue, completely Clap. From testing, it's important to remember to remove it for the application as well like you said, otherwise once blinky has ran, it has then executed its own CONFIG_GPIO_AS_PINRESET which effectively is the same as if not having removed it for the bootloader.

    Also, it isn't necessary to comment those entries in the Make file like I'd read about, nor was it necessary to write to PSELRESET like I had in main()

    Once again, thank you kindly Thumbsup

    Edit: Oh, and when blinky is running, pressing PB1 no longer stops blinky running... which makes it even more amazing Grinning

Related