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]

I'm not experienced with fault finding via debuggers, but I've made a very small start as per the screenshot below. Interestingly, both the DK and the Nano seem to get stuck in "crc32_compute(...)" (it gets stuck in the for-loop). But when I click the green arrow (continue execution) blinky then runs, when testing either device. Also, when it appears to be stuck, then after several "Step Over" and/or "Step Out" steps, followed by a continuation of "Step Into" steps, blinky also runs...

[Hung Bui]

Hi Gary, 

There is a function called dfu_enter_check(). It's where the bootloader check if it should stay in DFU mode or jump to the application. 

Could you check if any condition inside the function actually make the function returns true ? 

I suspect that NRF_BL_DFU_ENTER_METHOD_BUTTON was set to 1 and the NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN was not configured (or mounted) to correct level (active low I believe) causing the device entering bootloader mode. It's equivalent to the normal way of entering (secure )DFU of holding Button 1 when resetting the device. 

[GaryDT]

I can see: dfu_enter_check() within: nrf_bootloader.c. Via "Step Into" I can see which file is being executed because they're all open at the top of the main window and become highlighted one by one, and that function isn't reached, i.e., it just gets stuck in the CRC check.

Do you know why it continues on successfully... running blinky after clicking the green arrow (continue execution)? I.e., how does continue execution get it past the crc32_compute(...) function?

Within sdk_config.h: NRF_BL_DFU_ENTER_METHOD_BUTTON is set to 0 by default.

For: NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN I've changed the default 25 to 999 (Edit: 0 also makes no difference) in an attempt to disable its effect, but it made no difference. So to experiment further I then changed NRF_BL_DFU_ENTER_METHOD_PINRESET from 1 to 0, but that also still didn't make any difference, i.e., the Nano's yellow light is still on by default (without pressing its button) and nRF52 SDFU USB is listed under Ports in Device Manage. Please see SES screenshot below... (Edit: setting ...PINRESET to 0 does actually disable DFU mode... see my next post for clarification)

[Hung Bui]

Hi again Gary, 

You can simply test by removing the function and make it always return false to test. I guess there must be other reason why it enter DFU.

If you can use the log or a GPIO pin you can find which cause dfu_enter to return true. 

[GaryDT]

I've deleted my previous reply that was in this position, because it turns out that it was completely wrong...

Bizarrely, my two Micro-USB leads (probably PC related) that I've been using, each behave differently. They've both been working for programming purposes between themselves and the PC, but one of them doesn't (at least not consistently) enumerate as a COM Port in Device Manager, i.e., I've now swapped the leads over and I'm getting consistent behaviour for my Nano.

Edit: another thing was that Device Manager wasn't always refreshing after unplugging the nano, i.e., I had to hold its button pressed whilst unplugging it, or else it stayed listed under Ports. Anyway I've got the hang of all that now.

100% it's NRF_BL_DFU_ENTER_METHOD_PINRESET that is triggering DFU mode. It's set to 1 by default in sdk_config.h, and if I change that to 0, or instead comment the if-statement within dfu_enter_check() (see screenshot), then it never enters DFU mode. This is absolutely consistent now.

Therefore ...PINRESET is being activated by releasing the Nano's button. However, after having loaded blinky via nRF Util, and holding down the Nano's button whilst plugging it in, blinky still doesn't run. I wonder why?

I suppose the first thing to do is reverse the Low / High state of the button. Do you know if there's a setting for this?

Edit 2: also, please if possible can you explain how/where the nano's button press (or any other device's button press) is detected? And how it becomes associated with ...PINRESET?

Edit 3: according to the nano’s datasheet, reset is pin 6 (but I'm wondering if this is referring to (i.e., also connected to) its button PB1... maybe not?)