Bootloader in DFU mode doesn't respond (UART)

[QuentinD]

Hello

My application is based on your bootloader (secure_bootloader_uart_mbr_pca10056) and your example "ble_thread_dyn_mtd_coap_cli".

When I send a special command to my device (on the UART), it restarts and goes into DFU mode. To do this, I do as for the buttonless:

err_code = sd_power_gpregret_clr (0, 0xffffffff);
VERIFY_SUCCESS (err_code);
err_code = sd_power_gpregret_set (0, BOOTLOADER_DFU_START);
VERIFY_SUCCESS (err_code);
nrf_pwr_mgmt_shutdown (NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);

The problem I have is that the device no longer responds to UART commands after entering the bootlaoder.

Test performed:
1. Generate bootloader setting
2. Merge bootloader with bootloader_setting and the application and the softdevice
3. Flash the device
4. Send command to return in the bootloader and to switch in DFU mode
5. Send the "start packet" of DFU -> the device no longer responds

I noticed a strange thing ...
When I generate my complete.hex file from the secure_bootloader_uart_mbr_pca10056_debug, everything works fine. But if I do it with the other (secure_bootloader_uart_mbr_pca10056), I have this problem ...
If I do it with the normal bootloader (secure_bootloader_uart_mbr_pca10056) but I start debugging with my Segger (it rewrites the mbr and the bootlaoder before to begin the debugging) it also works ...

When analyzing the differences (after I started debugging), I notice that 2 addresses have been changed:
- 00FAE7E = 0x21 (before (NOK)) = 0x22 (after (OK))
- 00FAE80 = 0x22 (before (NOK)) = 0x21 (after (OK))

What are these addresses? Do you have any idea why it is only with the debug project that it works?

Thank you

[Edvin]

Hello,

Did you do any changes to the bootloader project in the _debug version that you didn't do in the normal bootloader? Or the other way around?

You say that the usb bootloader doesn't respond to uart messages. Does this also apply to uart messages coming from nrfutil? Or do you use some other method to transfer the packet?

Usually, I recommend customers to have a look at the _debug bootloaders when something doesn't work, although that will not work in this case, since the issue doesn't apply to the debug bootloader. To rule out some of the other suspicions I have:

-What does nrfutil say when you try to perform the serial DFU?

-Does it also happen in the unmodified bootloader from a new, unmodified SDK? What SDK version do you use, by the way?

-Did you try to use the maximum verbose flag? "nrfutil -v -v -v -v dfu serial ..."? What does it say then?

-Is this at all related to openthread, or can we exclude that? If you only program the mbr/softdevice, and the bootloader, does it work then?

-What changes did you do to the bootloader project? And what IDE did you use? Have you tried to move the flash start address down a large chunk, and increase the size for the bootloader, to see whether it is an overflow issue?

-What IDE did you use to compile your bootloader?

BR,

Edvin

[QuentinD]

By completely regenerating the DFU package and the production .hex file (containing the bootloader, mbr, softdevice and app), now it works.