Application partly unresponsive after dual-bank DFU update

[GPL]

Dear Nordic,

When testing the DFU process, I noticed something unexpected. We are using the secure DFU USB bootloader, with forced dual bank updating. I'll attach both the application and the bootloader sdk_config.h files below.
When uploading a new firmware image (the previous image was loaded via DFU as well), everything seemed to go smoothly and the nrfutil prompt reached 100%. Normally it then takes about a second or two to copy everything and boot, which is in our case noticeable by a vibration. This time there was no vibration and most other functionality also stopped working. But the weird thing is that the CLI interface (using the CLI module) was still working normally. Now trying to upload the same image again via the bootloader, nrfutil returned the 'Response Code InsufficientResources' error.

The fact that just a part of the functionality was working seems to suggest to me that a part of the application code was not transferred properly or was overwritten.

I think I might have configured some starting addresses, section sizes etc. wrong. Or possibly I misconfigured the reserved pages for the FDS in the DFU application? That at least seams the most logical explanation to me. Could you please check this for me? Attached you find my sdk_config.h files, and here's more information:

The size of the application image was ~380KB (~536KB was shown in SES, but that includes the 156KB reserved for SD).

nRF52840
Softdevice: s140 7.0.1

SDK: 16.0.0

DFU:

Memory Segments:
FLASH RX 0x0 0x100000;
RAM RWX 0x20000000 0x40000;
uicr_bootloader_start_address RX 0x10001014 0x4;
bootloader_settings_page RX 0x000FF000 0x1000;
uicr_mbr_params_page RX 0x10001018 0x4;
mbr_params_page RX 0x000FE000 0x1000

Section Placement Macros:
FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0xf0000
FLASH_SIZE=0xe000
RAM_START=0x20002260
RAM_SIZE=0x3fff8

Application:

Memory Segments:
FLASH RX 0x0 0x100000;
RAM RWX 0x20000000 0x40000;
UICR RX 0x10001000 0x304

Section Placement Macros:
FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0x27000
FLASH_SIZE=0xd9000
RAM_START=0x20002260
RAM_SIZE=0x3dda0
UICR_START=0x10001000
UICR_SIZE=0x304

Please let me know if I missed something.

- Gijs

P.S. Initially I thought the DFU banks would be of equal size, but I now understand that a dual bank update can (when initially empty) load an application 80% of the available size of bank 0+1, and after that only have room for an application of 20% of the size of bank0+1? That explains the error message received with second DFU attempt I think. And we will need to put in a warning system in our deployment system for applications which are too large.

sdk_config (Application).hsdk_config (DFU).h

[Hung Bui]

Hi Gijs, 

Please correct me if I'm wrong. What you tested was: 

- You flashed the nRF52840 with SD+BL+APP A (App A is relatively small in size)

- You did DFU to update to APP B (App B has larger size 380kB as you mentioned)

- The application B only work partly. 

- You tried to update APP B again but got InsufficientResources error. 

If that's the case what we can suggest you to try is: 

- Try to test SD+ BL (no application) and do DFU for APP B. Check if APP B works as it should. Try to read hex dump from the chip (nrfjprog.exe --readcode) 

- Repeat your initial step, after you update APP B and it works partially, try to read a hex dump and compare it with the hex at step 1. You can use Notepad++ to compare 2 hex files. 

You are correct about that if you force dual bank DFU update, the swap bank need to have enough space to receive the new image. This mean your application shouldn't be bigger than 50% of Bank 0+1 if you want to do another DFU update. 

It's quite strange that the application only works partly, I suspect that the error may related to that you have a bootloader and it may change the behavior of the app (it shouldn't)

[GPL]

Hello Hung,

Thank you for your response.

I had some trouble recreating this issue as I didn't have access to the binary that caused the issue at first because it was tested on an external location. So I tried it at home with binaries of the same size & even larger. It turns out then everything works okay. And now that I understand the dual bank process better, the insufficient resources error also makes sense.

I first flashed the SD and BL, then via DFU uploaded the smaller binary. Confirmed it was working and then update with the bigger binary, causing the issues. If I update to the bigger binary right away (so no previous application present) it also does not work fully. I tried compiling the binaries myself (the others were compiled on an external environment) and everything works okay!

So I guess something else went wrong caused by the other compilation process. Sorry, I should have done more research first.

Thank you for your time!