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

[QingF]

Hi : 

        Our project(SDK15.2) use the uart DFU to transfer the firmware , usually when the firmware has been transfered ,it can jump to app successfull .But Sometimes,bootloader can't jump to app after bootloader received the firmware compeletedly! We want to debug where it is failed ,but the log is stoped to print everytimes as follow:

<00> debug> nrf_dfu_settings: Writing settings...
<00> debug> nrf_dfu_settings: Erasing old settings at: 0x0007F000
<00> debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007F000, len=1 pages), queue usage: 1
<00> debug> nrf_dfu_flash: Flash erase success: addr=0x0007F000, pending 0
<00> debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007F000, src=0x20000734, len=348 bytes), queue usage: 1
<00> debug> nrf_dfu_flash: Flash write success: addr=0x0007F000, pending 0
<00> info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<00> debug> nrf_dfu_settings: Writing settings...
<00> debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000
<00> debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 1
<00> debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 0
<00> debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x20000890, len=348 bytes), queue usage: 1
<00> debug> nrf_dfu_flash: Flash write success: addr=0x0007E000, pending 0
<00> debug> nrf_dfu_req_handler: All flash operations have completed. DFU completed.
<00> debug> app: Shutting down transports (found: 1)
<00> debug> app: Resetting bootloader.
<00> info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<00> debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<00> info> app: Inside main

When it jump to app successfully,It will print the app's log immediately.If it is failed,it print nothing after the log   "<00> info> app: Inside main".

Can you give me some idea that let me know how to debug the fail cause  ???

Thanks!!

Best Regards!!!!

[Turbo J]

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:

1.  Reconnect the RTT client and manually set the address of the RTT data (e.g.  from map file).
2. 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.

[QingF]

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

[Hung Bui]

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.