Jump to ROM bootloader from application in i.MX RT1024

[dop]

Hi @all,

I'm trying to enter the ROM Bootloader in serial download mode from a running application on my i.MX-RT1024 custom board target. This is what I've accomplished so far:

// Bootloader API struct as described in RefMan 9.12 
struct bootloader_api_entry_t {
    void (*run_bootloader)(uint32_t const* arg);
    uint32_t const Version;
    char const* Copyright;
};
// Use 0xEB100000 as argument (as described in RM 9.10.2 of i.MX RT1010 since no such information could be found in the RM of i.MX RT1024) to enter serial download mode
constexpr uint32_t arg                  = 0xeb100000;
constexpr uint32_t BootloaderApiAddress = 0x0020001c;

auto const bl = *reinterpret_cast<bootloader_api_entry_t**>(BootloaderApiAddress);
// Jump to bootloader
bl->run_bootloader(&arg);

There are multiple things that appear to be weird:

- While the value of *Version* might be correct (0x10000) the copyright string appears to be incorrect

- After (supposedly) having entered the Bootloader, the MCU seems to immediately restart

What I'm I doing wrong? Am I supposed to use a certain BootMode configuration? Does the BT_FUSE_SEL need to be manipulated? What do I have to do to prevent the MCU from restarting and to force it to serial mode instead?

I've already managed to update the device by setting the BootMode pins and using the NXP SecureProvisioningTool along with the device specific Flashloader. But as there will be no more access to the pins in the final system, this solution will not be applicable once the device has been shipped to our customer.

I'm well aware that there are plenty of similar threads discussing this issue but I couldn't find a solution to my specific problem. Thanks in advance for any contribution on this topic.

[dop]

Here's a quick update on the issue: The copyright string is actually correct (apparently that was just an issue with the IDE). While I'm pretty confident now that the ROM bootloader actually is executed, I still couldn't manage to force it to stay in serial download mode.
I also made sure that `UART Serial Download Disable` fuse is set to `Disable/0` and even tried to make it work by setting the BT_FUSE_SEL and the WDOG_ENABLE fuse, but that didn't help either.
I really would appreciate some help on this as I'm running out of ideas.

[diego_charles]

Hi @dop 

I am sorry for the delayed response. Thank you for reaching us and for your update! 

What do you mean by I still couldn't manage to force it to stay in serial download mode?  Is the bootROM not responding to commands over SDPHOST?

Also,  I want to get more context about your application. what do you want to achive with re-invoking the bootROM?

Thank you!

Diego

[dop]

Hello @Diego_charle,

thank you for your response. I'm trying to provide a means to update the MCU's firmware during runtime. My idea is based on jumping back to the ROM bootloader in serial download mode using the ROM API (RM ch. 9.12) and waiting for an external host to write the NXP Flashloader binary into the device's RAM (sdphost). After that I plan to let the very same host use blhost to update the application.bin located in Flash memory.

I've already managed to perform an update of the application by forcing the device to boot in serial download mode (inlcuding the usage of sdphost+blhost) by setting the BootMode pins. Unfortunately, this will no longer be an option after having the final system shipped to our customer because there will be no access to these pins no more.

But when trying to make a jump to the ROM Bootloader in serial download mode from my application (ROM API), the Bootloader restarts my application without delay. (This is what I meant by "I still couldn't manage to force it to stay in serial download mode?")

I already tried to modify a very simple example project (led_blinky) to make sure there's no problem with the device configuration of my project. But even that didn't work.

As I wrote in my last update, I also activated the WDOG (RM ch. 9.9) and expected the ROM Bootloader to wait at least until the default WDOG timeout period of 64s is elapsed before jumping back to the app. But this had no effect either. There is no delay before the application code is executed again and therefore the Bootloader does not respond to any sdphost commands.

What am I missing? Am I doing something wrong in the code snippet that I posted? Or are there any particular hardware considerations to met?

Thank you very much for your support!

[diego_charles · Accepted solution]

Hi @dop 

Thank you very much for your interest on our RT10xxs and for your patience. 

I verified that the RT1020 bootROM does not support runBootloader API, the bootROM memory for the RT102x is much more limited that the RT1010 or RT1060 bootROM memory. The resets that you observed are the result of that. 

In your case, allow me to suggest you a secondary bootloader. MCU boot open source bootloader can be the base for your project, however we currently do not have a port for  the RT1024, it is available for the RT1020. If this bootloader is suitable as an option, I recommend checking the AN12878 Migration Guide from i.MX RT1020 to i.MX RT1024

The documentation for this bootloader can be found here https://docs.mcuboot.com/ 

Feel free to  let me know any comments or further related questions you may have. 

Best regards