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

bad application behavior after bootloader DFU

Hi all,

I'm using SD S132 v5.0.0 with SDK 14.0.

I'm testing now the BL buttonless DFU (and later the SD buttonless DFU) after working well with the app buttonless DFU.

The app DFU is working well (dual bank and single bank). For the BL DFU, after the DFU procedure, the application gets into some weird behavior (looks like too fast freertos ticks). and that requires reset to recover (soft or power reset)

Using some comparing BL logs between the app DFU and the BL DFU, I'm seeing that the BL is missing some soft reset before launching into application according to code documentation, that should be triggered in this procedure:

        // Upon successful completion, the callback function will be called and reset the device. If a valid app is present, it will launch.
    NRF_LOG_DEBUG("Writing settings and reseting device.");
    ret_val = nrf_dfu_settings_write(reset_device_callback);

However, the last lines of the log are the following: pastebin

Meaning, that nrf_dfu_reset_timeout_handler is never called and the app is launched without this reset.

More parameters:

  • Secure bootloader is the same as in example, except for setting 3 GPIOs to HIGH and removing the button.
  • NRF_DFU_POST_SD_BL_TIMEOUT_MS is set to 10000 (default value)

Am I interpreting this correctly? Do I need this missing reset for the application to boot up cleanly?

Thanks

  • Hi gkovelman_tap. Sorry for the delayed response. Could you explain your comment "the application gets into some weird behavior (looks like too fast freertos ticks) and that requires reset to recover" in more detail please? I talked to a colleague of mine, and he believes that you maybe should not be expecting a timeout, but instead that the application starts running directly after the bootloader is updated. I will test this same setup tomorrow. Also, I am not sure if this will help, but could you try using SDK 14.2 instead of 14.0? Not sure if it makes a difference, but it might be worth trying out.

  • I tested the buttonless dfu example and it worked without any issues. What I did was follow the secure dfu blogpost first. Do the exact same things in Step A & B. Build the secure dfu bootloader. In step C, use the built buttonless secure dfu hex file instead of the secure dfu hex file. Then, remember to use the buttonless dfu application hex file instead of the secure dfu hex file. Also, remember to use the correct hexadecimal code for the softdevice you are using. If you are using the 5.0.0 SD, the code is 0X9D. You can use the command nrfutil pkg generate --help to check if you are using the correct hexadecimal code. Then, use the nrf toolbox app for iOS/Android to upload the DFU using the DFU app. When the app reaches 100%, it should start advertising automatically as DFU Buttonless (or something similar).

  • Then, you can use the same nrf toolbox app, press on the DFU service & try to do a DFU again. If everything worked fine, the DFU should be succesful. Hope that helps!

  • I'm having trouble further explaining the behavior since I don't know what to investigate in the application after the BL DFU. It looks like bad peripheral configurations such as clocks and interrupts, like after an unclean jump to the application from the bootloader.

    According to the documentation in the code, I should expect a timeout which triggers a reset and then a jump to the application but I'm experiencing a direct jump to application after modifying the flash content, so I can't really understand what's the correct behavior.

    Thanks for the tips. I'll try it out and let you know.

  • I've had some more time to investigate this.

    In the bootloader, stopping the post SD and BL reset timer (nrf_dfu_post_sd_bl_timeout_timer_id in nrf_dfu_utils.c) right before loading the app (// Uninitialize the clock driver to prevent interfering with app.) fixed this.

    This timer was not stopped nor triggered when performing BL-only DFU so it interfered with the app's flow.

    I hope it'll help others.

Related