Sometimes,bootloader can't jump to app after bootloader received the firmware compeletedly!

RE: Sometimes,bootloader can't jump to app after bootloader received the firmware compeletedly!

Hung Bui — Mon, 30 Mar 2020 14:00:01 GMT

Hi Qing,

First please verify that it was just the log stopped after "<00> info> app: Inside main" or also your application couldn't start ?

Does your app require softdevice ?
If you test with a simple app for example blinky LED , would DFU work all the time ?
How often do you see the issue ?
If you want to debug the bootloader, you can change the optimization level to 0 and step into the bootloader, add breakpoints, etc. Because of the optimization level reduced, the size of the bootloader may be increased and wouldn't fit in the original location. You need to move the bootloader down to make more space for it. Make sure you do an eraseall before you test the bootloader with the new location.

RE: Sometimes,bootloader can't jump to app after bootloader received the firmware compeletedly!

QingF — Mon, 30 Mar 2020 12:42:51 GMT

Hi Turbo J:

Our APP use the 13.0.0 SDK ,and the bootloader's version is 15.2 SDK. Because I want to use the 15.2 tool of https://github.com/jimmywong2003/nrf-slim-serial-uart-dfu-host-c-code to implement the DFU function. But it always maybe failed to jump to app after received all firmware.

If you have the c code tool that its version is 13.0.0 ?

Thanks

RE: Sometimes,bootloader can't jump to app after bootloader received the firmware compeletedly!

Turbo J — Sat, 28 Mar 2020 08:00:27 GMT

That might be just SERGGER RTT derping out.

Cause: Application and bootloader use different memory segment for the RTT data communication.

Bootloader RTT segment might end on an address that is later in softdevice reserved RAM due to different configuration settings for the application.

Workarounds:

Reconnect the RTT client and manually set the address of the RTT data (e.g. from map file).
Overwrite (set to zero) all memory that is not (yet) reserverd by the softdevice, i.e. the softdevice reserved area minus the first 8 bytes BEFORE softdevice is turned on. This should erase the "old" RTT signature from its RAM location and for RTT to search for the new one.