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

Understanding bl_boot() - DFU Mode

Hi,

I changed application main.c to enter in to DFU mode after 20 seconds. System is reset every 20 seconds and the boot messages are printed. The message "Booting (0x8200)" inside bl_boot() is also printed. The reset handler is called at the end of the function. However, it resets the device but bootloader main() is never called and the device never enters the DFU mode.

There are 3 main() functions are involved:

Application main() - setup to enter the DFU mode (I am using GPREGRET register and system reset)

nrf main()  - Validate MCUboot and boot (No change by me)

mcuboot main() - Enter DFU mode (No change by me)

Really appreciate if someone could explain what is going on in this case and what is missing?

Thanks,

Ram

Parents
  • Hi,

    Just to confirm, are you looking to do serial upgrade within the bootloader itself? In that case, I will check with the team if there are any preferred methods to put the device into DFU mode. As far as I can tell, the update image is usually received and stored by the main application by using the mcumgr (NCS FOTA upgrades), where MCUboot has the responsibility of validating and activating the new update at the end, as the final step of the upgrade process.

    Best regards,

    Vidar

Reply
  • Hi,

    Just to confirm, are you looking to do serial upgrade within the bootloader itself? In that case, I will check with the team if there are any preferred methods to put the device into DFU mode. As far as I can tell, the update image is usually received and stored by the main application by using the mcumgr (NCS FOTA upgrades), where MCUboot has the responsibility of validating and activating the new update at the end, as the final step of the upgrade process.

    Best regards,

    Vidar

Children
  • Hi,

    Thanks for your reply!

    Yes, I want serial upgrade (thru SPI interface) within the bootloader, and I am using GPREGRET register and system reset in the application main to enter the bootloader. It is happening now but only with the SES build, not the west build for some reason.

    I really want to understand the booting process (at the code level starting from reset to application main) where it jumps to bootloader main and the application main.

    Could you please explain me setup to debug the bootloader code?

    Thanks,

    Ram

  • Hi Ram,

    Thanks for confirming. For debugging, do you use GDB, Ozone, SES, or something else? In either case, it should work as long as you  remember to load the symbols file (*.elf) from the MCUboot build instead of the app (ozone does not support multiple symbols file as far as I know).

    Hitting breakpoint in bootloader main()

    Maybe you have seen it already, but the boot sequence is described here in the NCS documentation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bootloader.html (Note: the immutable bootloader is optional). Please let me know if there is something you feel is missing.

    Best regards,

    Vidar

Related