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

[GaryDT]

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.

[GaryDT]

Hi Hung,

Please also see my previous reply.

I've tried by using a separate button attached to the Nano... METHOD_BUTTON_PIN 43 (P1.11), and it works 100% as expected, i.e., enters DFU mode only when the button is pressed and then plugging in the USB, otherwise blinky always runs.

Incidentally, pressing the button whilst blinky is running temporarily stops it running (i.e., all LEDs turn off) until the button is released. Any idea if that's a soft reset? Or maybe a built-in hardware feature? (Photo of my setup is below for reference)

Further research: this guy was having similar problems with the PSELRESET register. Please note that I've already tried the following (for open bootloader only (on its own) that is) as per the quote below...

I've already commented out the CONFIG_GPIO_AS_PINRESET flags in my Makefile and I've searched for that exact text in my entire project and it isn't defined anywhere else

Here's my Open Bootloader's Makefile with commented: #CFLAGS += -DCONFIG_GPIO_AS_PINRESET

Also, within dfu_enter_check() ...

if (NRF_BL_DFU_ENTER_METHOD_BUTTON &&
(nrf_gpio_pin_read(NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN) == 0))

nrf_gpio_pin_read(...) always returns 1 for my Nano's "<18=> 18 (P0.18)" pin when PB1 is in its released logic-high state, which I guess is correct, the same as for the DK. But as I mentioned earlier, when PB1 is kept pressed, it's as if the Nano is effectively powered down, which I suspect might be the problem because that would mean logic-low is never read, i.e., PB1 is released which effectively turns it on, and then PB1's logic-high is read which of course doesn't activate DFU mode.

If the above is true, then do you know if this powering down like behaviour can be configured, such that PB1 (ResetN) can be made to operate like a separate button? (As you might have guessed, I'm not feeling very confident that PSELRESET is the issue, but I hope I'm wrong). 

To recap regarding my dfu_enter_check() function, here it is again with respect to the above...

I'll wait for your reply, thank you kindly.

P.S. I'm trying to avoid using Arduino's Bossac as explained by Kevingre (Post #4).

[GaryDT]

Sorry my mistake... I was looking at the wrong chip. I had several tabs open and somehow the contents column on the left didn't match the main content on the right. Here's the correct PSELRESET from earlier.

Don't worry, I'll tidy up any consequential mistakes to keep things as coherent as possible  

[Hung Bui]

Hi Gary, 

To modify UICR you would need to enable writing to flash (WEN)

It's already prepared in the code of most of the application, by enable or disable CONFIG_GPIO_AS_PINRESET in the preprocessor symbols. if you look at system_nrf52.c (line 290), you can find how it's done. 

So in your case, if you want to disable the pin as a reset pin, you need to remove CONFIG_GPIO_AS_PINRESET in the preprocessor in both the bootloader and the application project. And make sure you erase the chip before you flash it again. 

I'm not sure why press and hold the button P1.11 would cause the chip to reset. You may want to check if pressing it actually cause a short some where in the circuit. Please try to test on another pin (without modifying the code) to see if it's only that pin causing the reset. 

Another thing to test is to flash only the blinky example, without the bootloader, and check if pressing the button cause any effect. If it doesn't then there must be something in the bootloader causing the trouble. 

[GaryDT]

When only having blinky programmed directly from Segger, then PB1 does still stop it running whilst the button is pressed, and then it starts again when released. So it can't be the bootloader.

It doesn't feel like a short (or smell).

Anyway, I'll work this afternoon to try the other things you have suggested and get back to you here. Again sorry about the wrong table... I'll carefully tweak anything that needs slight attention as I said.

Thanks again. 

[GaryDT]

It's already prepared in the code of most of the application, by enable or disable CONFIG_GPIO_AS_PINRESET in the preprocessor symbols. if you look at system_nrf52.c (line 290), you can find how it's done.

"preprocessor symbols"? But you then refer to file system_nrf52.c to accomplish it. I'll assume you mean Preprocessor Definitions in Segger as below, but please correct me if that's not what you meant. I'll also look at that file...