dfu upgraded app wont boot

[feran]

Hi,

When upgrading the DFU with an app everythings goes seemingly fine, all init+app bytes received, validated and so on. The DFU does its resets when done updating settings page and activating the new app fw. Something is wrong because after jump_to_addr() we'll end up somewhere which is not the start of my application.

Device: nRF52840

SDK: 16.0.0

Ported secure dfu: pca10056_uart_debug example

DFU Modification: Added a CAN transport instead of the UART transport, and not using slip encoding. Have not touched any other file but sdk_config.h for enabling the SPI interface to the CAN controller.

App example for tests: blinky_PCA10056_mbr

Package generation: nrfutil pkg generate --key-file myKey.pem --application blinky_myBoard_mbr.hex --hw-version 52 --sd-req 0 --application-version 1 blinky_myBoard_mbr.zip

IDE: Segger Studio

nrfutil version: 6.0.1

My real application is using the softdevice, but I present this simple MBR example which shows same error behaviour. Otherwise I have successfully generated SD packge, App package, and sent them over CAN to DFU one after the other and all is good until the jump to address 0x1000 which fails.

I'm thinking this seems like a linking problem but I have not been able to what I'm doing wrong.

[bjorn-spockeli]

feran said:

That is an unfortunate issue. Is this documented somewhere, maybe any workaround or future fix for making the DFU robust for different optimization levels? For now using the Release configuration/Size-Optimize is the only option for production.

 This will be addressed in the next release of the nRF5 SDK. 

feran said:

1. After upgrading the chip, loaded with Release-Bootloader+SD v7, with first version of my application which among other have RTT logs enabled, the RTT output stops after the jump to the application. The rest of the app seem to execute fine, tested for 12h at least. There is only one method I managed to get my periodic RTT outputs show up with. If I power-cycle the my PCB, connect with J-Link RTT Viewer, then program and run the chip with the my DFU project in Segger Studio, the logs comes out sometimes in the RTT Viewer and sometimes in the SES. Is this a known behavior?

When you use RTT logging in both the application and bootloader then on boot the bootloader will initalize the RTT control block in RAM. When you jump to the application it will also initialize its RTT block in RAM. When you connect to the device in a debug session or RTT viewer, then its a bit random which RTT control block that the debugger finds. 

It is possible to place the RTT control bloc at a static location in ram see https://devzone.nordicsemi.com/f/nordic-q-a/30310/easy-way-to-merge-bootloader-and-application-rtt-output

 

feran said:

2. I have compared the app binary content and placement in flash and found just a pair of difference which probably just are padding FF bytes that the nrfutil puts there, but I want to get this confirmed with you to be sure.

Addr offset 0x244C0: 04 0B FF F7 E1 FF BD E8 08 40 04 B0 70 47 FF FF. The last two bytes are 00 00 in the original binary/hex fed to nrfutil. The second difference is the last byte at address 0x2EDB0: 6C 29 00 FF which also is originally a 00.

Yes, this is padding to make it word aligned I think

Best regards

Bjørn