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

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

GaryDT — Mon, 03 Jan 2022 17:33:06 GMT

Hi Hung,

Awesome! it works perfectly.

Removing CONFIG_GPIO_AS_PINRESET from the preprocessor definitions has fixed the issue, completely 👏. 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 👍

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

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

GaryDT — Mon, 03 Jan 2022 15:30:28 GMT

[quote]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.[/quote]

"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...

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

GaryDT — Mon, 03 Jan 2022 15:12:10 GMT

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.

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

Hung Bui — Mon, 03 Jan 2022 15:05:07 GMT

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.

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

GaryDT — Mon, 03 Jan 2022 15:02:51 GMT

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 😨

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

GaryDT — Sun, 02 Jan 2022 09:49:37 GMT

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...

[quote]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[/quote]

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

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

GaryDT — Thu, 30 Dec 2021 15:23:32 GMT

Hi Hung,

I meant happening regarding why 14 and 15 are doing what 18 should be doing 😀 but please notice my Edit 3 which attempted to explain (although I didn't know about soft reset and power reset, thanks, and for anyone curious... Reset Behaviour

Anyway to now continue on from here by disabling PSELRESET as you've suggested... I've disabled both [0] and [1] because I don't know which one is relevant. I searched the entire solution for PSELRESET to avoid it being set after wherever I disable it, but it isn't found, so I decided to add them in main() as below...

int main(void)
{    
	NRF_UICR->PSELRESET[0] = UICR_PSELRESET_CONNECT_Disconnected << UICR_PSELRESET_CONNECT_Pos;
	NRF_UICR->PSELRESET[1] = UICR_PSELRESET_CONNECT_Disconnected << UICR_PSELRESET_CONNECT_Pos;
	
	uint32_t ret_val;
	
	// Must happen before flash protection is applied, since it edits a protected page.
	nrf_bootloader_mbr_addrs_populate();
	
	// Protect MBR and bootloader code from being overwritten.
	ret_val = nrf_bootloader_flash_protect(0, MBR_SIZE);
	APP_ERROR_CHECK(ret_val);
	ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR, BOOTLOADER_SIZE);
	APP_ERROR_CHECK(ret_val);
	
	ret_val = NRF_LOG_INIT(app_timer_cnt_get);
	APP_ERROR_CHECK(ret_val);
	NRF_LOG_DEFAULT_BACKENDS_INIT();
	
	NRF_LOG_INFO("Open USB bootloader started");
	NRF_LOG_FLUSH();
	
	ret_val = nrf_bootloader_init(dfu_observer);
	APP_ERROR_CHECK(ret_val);
	
	NRF_LOG_FLUSH();
	
	NRF_LOG_ERROR("After main, should never be reached.");
	NRF_LOG_FLUSH();
	
	APP_ERROR_CHECK_BOOL(false);
}

The result is exactly as before when not using pins 14 or 15... as the workaround that I discovered.

Therefore, might PSELRESET be set after main() via some other method?

Please confirm if I'm disabling this register correctly?

Edit: just to confirm (although probably not surprising considering all that has tested to work so far), I am indeed using the _mbr version as below...

nrfutil pkg generate --application blinky_pca10056_mbr.hex --application-version 1 --hw-version 52 --sd-req 0x00 app_dfu_package.zip
nrfutil dfu usb-serial -pkg app_dfu_package.zip -p COM13 -b 115200

Edit 2: I've discovered how to see the registers in SES 🤔 here's a screenshot whilst in debug mode. You can see that both PSELRESET [0] and [1] state "Disconnected" (by default that is, i.e., my attempt to disable them in main() is commented). I'll wait for your reply, thank you...

And for the PIN field I can only see one possible value... 18 (Please see screenshot below) so I'm guessing that doesn't apply, or does it?

Edit (03-01-2022): the screenshot below is now for the correct chip (nRF52840), otherwise I would have asked about PORT as well 😐

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

Hung Bui — Thu, 30 Dec 2021 14:20:52 GMT

Hi Gary,
Sorry it was my mistake, my intention was to set NRF_BL_DFU_ENTER_METHOD_BUTTON =1 not NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN = 1.

After you set NRF_BL_DFU_ENTER_METHOD_BUTTON =1 you then choose a PIN to be used as the reset to DFU pin. Let's say pin P0.05. Then to switch to DFU mode you need to hold the button that connect to P0.05 and do a reset, either a softreset, pin reset or a power reset.
When the bootloader booting up it will read the value of P0.05 and decide to enter DFU mode or not. It's not a GPIOTE event, but simply a pin read before entering DFU.

If you don't have an extra button to use and only have one single button PB1 that connect to P0.18 then you need to disable P0.18 as a reset pin ( via PSELRESET register) and set NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN to P0.18

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

GaryDT — Thu, 30 Dec 2021 13:40:22 GMT

Is the correct solution to setup a GPIOTE for the Nano's PB1 button in my application via P0.18? Or is PB1 already configured as input? in which case this relates back to my Edit 4. Maybe similar to your reply in the thread as quoted below...

...Buttons don't work with a bootloader

[quote]The bootloader I provided doesn't use GPIOTE Port event. It configures one button as input. As suggested by RK, have you made sure you reconfigured the button correctly in your application ?[/quote]

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

GaryDT — Wed, 29 Dec 2021 13:09:55 GMT

Thanks Hung,

Did you mean to say NRF_BL_DFU_ENTER_METHOD_BUTTON to 1 (0 is the default)? If not then...

For NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN (25 is the default). Therefore why set it to 1?

[quote]You can disable pin reset if you want (change PSELRESET register).[/quote]

Is that necessary considering that NRF_BL_DFU_ENTER_METHOD_PINRESET 0 disables activating DFU mode by ignoring the pin reset event? (Or do you mean that if I ever want to disable pin reset in general, then I can use its register?)

[quote]In many applications, you don't want to enter DFU mode every time you do a pin reset, but instead having an extra button to switch it to DFU mode.[/quote]

Ah, so the Nano's reset button is essentially for resetting all pins, which is done by it being connected to P0.18. So you're simply saying to disable pin reset by setting _METHOD_PINRESET to 0 (or disable the pin reset event directly via its register, as mentioned above), and therefore the Nano's PB1 button can be used to activate DFU mode via _METHOD_BUTTON instead, and therefore as a point of interest, I suppose the button press itself must be registered independent of the pin reset event...

I've checked, and the Nano's button PB1 is indeed connected to P0.18, and so I've tried with _METHOD_BUTTON 1 and _METHOD_BUTTON_PIN 18 (_METHOD_PINRESET 0). The result is...

Me remembering to uncomment previous changes to avoid being called a "Wally" 😀
Bootloader detects no valid application and therefore enters DFU mode = correct.
Flash board with blinky via nRF Util and blinky runs = correct.
Press PB1 which stops blinky running (i.e., all LEDs off) = correct, but it doesn't enter DFU mode = wrong. Also, blinky resumes running after releasing the button.

I'll keep trying, but please if possible kindly respond to my previous questions, and let me know your further thoughts.

The schematic is below (1st zoomed, 2nd full view)

Edit: _METHOD_BUTTON 1 & _METHOD_BUTTON_PIN to either 14 or 15 seems to work perfectly as below (also METHOD_PINRESET 0 of course)

Bootloader detects no valid application and therefore enters DFU mode = correct.
Flash board with blinky via nRF Util and blinky runs = correct.
Press PB1 (sometimes requiring to keep it pressed for about 0.5 to 1 second) stops blinky running and then enters DFU mode when PB1 is released = seems to be correct.
Press PB1 again and blinky resumes running = correct.

However, how does it make any sense that it works for pins 14 and 15 and not others, including 18? (it was by pure chance that I changed the pin to 15, and so I then tested a few other values in my disbelief).

Edit 2: this would be a celebration if I understood what was happening ⁉ ☺

Edit 3: so P0.14 (SDA1) and P0.15 (SCL1) are the I2C bus as stated for U-Blox NINA-B3X in the above schematic, and interrupting either of those two pins (which must be caused by pressing PB1), more or less consistently toggles between DFU mode and running blinky. Maybe this is just a lucky fluke? ... Incidentally, _METHOD_BUTTON_PIN 25 (the default) is button 4 on my nRF52840-DK 👌 (I should have spotted that before).

Edit 4: how is the SDK registering/configuring the Nano's button press, considering that it doesn't work for _METHOD_BUTTON_PIN 18 as explained above? (virtually the same question as "Edit 2" in my last reply).

I'll wait for your reply, and thank you kindly Hung for your support so far. Cheers!

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

Hung Bui — Wed, 29 Dec 2021 11:13:57 GMT

Hi Gary,

The reset pin of nRF52840 is pin P0.18. Please double check on the schematic of the Nano board (and the ublox module) to see how P0.18 is connected.

You can disable pin reset if you want (change PSELRESET register).

In many applications, you don't want to enter DFU mode every time you do a pin reset, but instead having an extra button to switch it to DFU mode. If it's the case you need to modify the NRF_BL_DFU_ENTER_METHOD_PINRESET to 0 and NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN to 1.

Another test you can do is to flash a normal application (not the bootloader) and do a power reset on the Nano, and check the value of NRF_POWER-> RESETREAS register to double check if reset pin is always triggered on power reset.

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

GaryDT — Tue, 28 Dec 2021 17:43:38 GMT

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

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

Hung Bui — Tue, 28 Dec 2021 15:01:19 GMT

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.

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

GaryDT — Tue, 28 Dec 2021 14:34:17 GMT

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)

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

Hung Bui — Tue, 28 Dec 2021 13:35:57 GMT

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.

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

GaryDT — Tue, 28 Dec 2021 11:04:42 GMT

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...