DFU Fails on nRF5280, loop on nRF Connect

RE: DFU Fails on nRF5280, loop on nRF Connect

Federico — Mon, 05 Dec 2022 13:08:13 GMT

Hi Hung,

Found it. It was the bootloader linker file, there was not enough RAM allocated for the SoftDevice. Since I migrated the project from a S112 example, the linker was set for that amount of RAM:

define symbol __ICFEDIT_region_RAM_start__ = 0x200022c8;

After migrating to S113, it appears that amount of RAM is not enough. So I changed it to what the secure_bootloader example has for this SoftDevice (which is exactly what nrf_sdh_ble_enable returns). Now DFU is successful. As the bootloader project doesn't have a log, I didn't see the error as you'd see in app when starting the SoftDevice fails.

The new config is:

define symbol __ICFEDIT_region_RAM_start__ = 0x20002608; /* This is taken from calling nrf_sdh_ble_enable(), calculated at runtime by the SoftDevice. */

Thank you!

RE: DFU Fails on nRF5280, loop on nRF Connect

Hung Bui — Mon, 05 Dec 2022 11:33:40 GMT

Hi Federico,
I don't see any reason it shouldn't work. Have you tried to do the change with a normal application (not bootloader) and check if it works ? (only softdevice + bootloader)
You may want to try testing with the bootloader debug version and step into the code to see what caused the issue.

Please make sure you make an full chip erase before testing there is a chance that there was something in the UICR that has not been erased from the previous bootloader.

RE: DFU Fails on nRF5280, loop on nRF Connect

Federico — Fri, 02 Dec 2022 21:17:47 GMT

Hi Hung, thanks for answering both questions. Let's try to solve this one first.

I tried what you said in step 1: "Flash only softdevice + bootloader. Try to do DFU update a ble_app_hrs for example".

I did this with "ble_app_uart_pca10100_s112" instead of ble_app_hrs because it supports PCA10100e. For the bootloader image, I compiled the secure_bootloader example "secure_bootloader_ble_s112_pca10100e". This worked without issue. I flashed it, saw the device as DFUTarg, ran the DFU and ended up with a device "Nordic UART". So that worked.

I then tried to do the same thing with my bootloader hex file but it didn't work. I can't see the device as DFUTarg. This is very interesting, because my bootloader code basically has zero differences from the example "secure_bootloader_ble_s112_pca10100e". The two differences that I can see are: the public key and the soft device. I changed the softdevice to 113 instead of 112 to have DLE. The way I did this was to change the includes in the preprocessor from 112 to 113, change the define from S112 to S113 and swap the soft device binary. Is this correct? Or did I miss something? Could this be the issue?

EDIT: I went back to SoftDevice 112 on my bootloader code and now I can see it as DFUTarg, so this seems like the obvious reason, I must've forgotten something when changing the soft devices. What do I need to do to change the "secure_bootloader_ble_s112_pca10100e" example to be able to run with S113? Keep in mind I'm using the 52833DK emulating a 52820.

Thanks!

RE: DFU Fails on nRF5280, loop on nRF Connect

Hung Bui — Wed, 30 Nov 2022 12:29:25 GMT

Hi Federico,

It seems that the application managed to jump to the bootloader but then the bootloader rejected the DFU image:

We need to check why it doesn't want to do DFU update.

My suggestion to test is not to start with the buttonless example.
Please try the following:

1. Flash only softdevice + bootloader. Try to do DFU update a ble_app_hrs for example.

2. Flash softdevice + bootloader + ble_app_hrs + bootloader setting. Create a new image of ble_app_hrs and create a new DFU .zip file with incremented firmware version. Try to do DFU to update to this new ble_app_hrs via FOTA. You can enter DFU mode by holding a button when reset.

3. Flash softdevice + bootloader + buttonless application + bootloader setting. Create a new image of buttonless application with new firmware version and create a .zip file. Do DFU update.