This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK 17.0.0 Bluetooth DFU example not work

I am tring to DFU by Bluetooth with example, but it not work.
Please someone help me!!

My environment
PCA10056 nRF52840
SDK17.0.0
examples/dfu/secure_bootloader/pca10056_s140_ble_debug

First flash the program by onboard J-link.
The program print "before" in main().
Next, build and pack target program.
The program print "after" in main().
DFU by nRF Toolbox on iPad.

Outputted "All flash operations have completed. DFU completed." on terminal.
It indicates that reached on_dfu_complete().
But, "after" is not displayed.
Parents
  • 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.)

  • 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?

Reply Children
No Data
Related