SDK 17.0.0 Bluetooth DFU example not work

RE: SDK 17.0.0 Bluetooth DFU example not work

Hiroyuki Kanai — Mon, 31 Aug 2020 00:23:46 GMT

OK, I will try it

RE: SDK 17.0.0 Bluetooth DFU example not work

Einar Thorsrud — Fri, 28 Aug 2020 09:27:46 GMT

Hi,

Thank you for the log. I do not see any indication of a problem there, but there are several things I would expect to see which are not there. For instance, the last part of the log is like this:

00> <debug> nrf_dfu_req_handler: All flash operations have comp<error> app: main() address : 0xF3E2D
00> 
00> <error> app: before!!
00> 
00> <error> app: Inside main 09:04:03

The line with "nrf_dfu_req_handler" is from the bootloader, and the next is from the application. But there is no trace of the bootloader resetting after the update and branching to the application, which would always be the case, and should always be in the log (for instance "Running nrf_bootloader_app_start with address"...).

One typical reason for missing / corrupt RTT logs is when, as in your case, both the bootloader and application use RTT logging. Perhaps you could disable RTT and use UART in the app instead? You could also use different LEDS or similar to indicate which app version is running.

If you still get a strange log after changing this, can you describe in full detail how you test and any changes you have made to the bootloader example?

RE: SDK 17.0.0 Bluetooth DFU example not work

Hiroyuki Kanai — Fri, 28 Aug 2020 00:08:49 GMT

Thanks for your advice!!
I got the log now.
devzone.nordicsemi.com/.../DFU_5F00_log_5F00_0828_5F00_0904.log

RE: SDK 17.0.0 Bluetooth DFU example not work

Einar Thorsrud — Thu, 27 Aug 2020 11:25:53 GMT

Hi,

Your test seems sensible, updating from a firmware that writes "before" to "after". There is nothing here indicating what went wrong, though. I see you are already using the debug bootloader (pca10056_s140_ble_debug), which include RTT logging. Can you do the process again and upload the RTT logs here? It is interesting to see the logs both from the update, and from when (failing to) starting the new application. That should give a good indication of what the problem could be.

(You can obtain the logs using the J-Link RTT viewer.)