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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related