RT1024 initial programming and BOOT_MODEx pins

[davenadler]

We're trying to finalize a design with MIMXRT1024CAG4B and I'm unclear about boot configuration and initial programming during production.

Background: Product will use RT1024's internal flash and SRAM only, and USB host with USB memory stick. Bootloader will check for a new image on USB memory stick at boot time and reflash if present, then jump to our application. I don't think we want to use builtin (ROM) serial bootloader at any point during production, as it requires additional hardware connectivity.

Questions: What are the steps to get from a board with a new unprogrammed RT1024 (which wants to immediately jump to bootloader for serial load) to a board with our own bootloader loaded? Can we load the bootloader and configure the chip (fuses) via the JTAG/SWD connector? What BOOT_MODEx pin inputs are required?

Thanks!
Best Regards, Dave

PS: Also, is bootload-from-USB-stick (USB Host) a supported configuration in MCUboot now (or do I have to implement this, again)?

[jay_heng]

Yes. you can load the bootloader into RT1024 internal Flash via the JTAG/SWD connector, but it is not easy to configure the chip (fuses) by this way as well, unless you modify debugger flashloader algo to add fuse programming code.

If you flash the board by HW debugger, you don't need to care about the BOOT_MODEx pins (just keep them as 2'b10).

What do you mean about MCUboot ? is it BootROM? if so, BootROM doesn't support bootload-from-USB-stick (USB Host)

[davenadler]

@jay_heng- I am surprised you do not know about MCUboot, please review this:
https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcu-bootload... 

I understand I can program the flash via SWD/JTAG.
But what exactly are the steps and required configuration settings to get from:
- an unprogrammed RT1024 on a new board, to
- a RT1024 that will boot into our bootloader?
Including setting fuses as seems to be required? Again...

Questions: What are the steps to get from a board with a new unprogrammed RT1024 (which wants to immediately jump to ROM bootloader for serial load) to a board with our own bootloader loaded? Can we load the bootloader and configure the chip (fuses) via the JTAG/SWD connector? What BOOT_MODEx pin inputs are required?

Thanks,
Best Regards, Dave

[jay_heng]

It is BootROM flashloader, and there is another MCUBoot in SDK.

For your question, just below two steps:

1. Load the bootable binary into unprogrammed RT1024 board by HW debugger (if you don't know what bootable image is, you have to try MCUBootUtility tool or MCUXpresso Secure Provisioning Tool)

2. Keep the BOOT_MODEx pins to 2'b10

[davenadler]

@jay_heng- Your answer is incomplete as that does not set the fuses.
Perhaps you can find someone more experienced to answer this question?
Thanks,
Best Regards, Dave

[mjbcswitzerland]

Hi

See https://www.utasker.com/iMX/RT1024.html
You just have to set Mode00 to '0' and Mode01 to '1'. This will boot to ISP mode when the flash is empty and so can be programmed by LPUART, USB-HID or by JTAG/SWD.
Once a valid FW is in the Flash it will then boot from there.
In case you need to get back to ISP mode you can erase the Flash via JTAG (or use DIP switched to set Mode00 / Mode01 to '10').
You can program eFUESs via ISP or also directly from the application that is running, but programming eFUSEs is not usually needed (it is not recommended to disable JTAG/SWD via eFUSEs on the i.MX RT 1024 since it can cause loss of the chip if there is a bad application loaded that doesn't allow return to ISP mode).
There is a USB-MSD (memory stick) serial loader supporting encrypted or non-encrypted operation in XiP or SRAM available off the shelf if needed:
https://www.utasker.com/docs/iMX/Loader.pdf
https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
Users guides: https://www.utasker.com/iMX/developers.html
Video guides: https://www.youtube.com/watch?v=GXztWg9m6_8&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe

Regards

Mark

[davenadler]

@mjbcswitzerland- Thanks Mark. I plan to only implement USB Host on our board. It seems my options to get from initially produced board to something useful are:

1. Add USB OTG hardware (power switching etc), and use built-in ROM bootloader to load my application/bootloader and blow required fuses via USB-HID using NXP's utility, or
2. Do the initial programming via SWD, and immediately start the downloaded program. The program can set the fuses to boot from flash next time (if the fuses aren't already set).

I reviewed the RT1024 reference manual and I don't understand what you mean "Once a valid FW is in the Flash it will then boot from there" - I don't see any description of a check for a valid image in the serial downloader configuration. What am I missing? I understood I need to set fuses...

Glad to see your bootloader supports USB host mode - maybe we can use yours as it appears NXP has still not implemented USB host support in NXP's MCUboot.

Thanks again,
Best Regards, Dave

[mjbcswitzerland]

Hi Dave

If the i.MX RT boots from QSPI flash it will first check that the code in flash has a valid flash configuration header. If it doesn't (like when it is fresh with the QSPI flash in an erased state) it will fall back to its ISP mode. Therefore eFUSES are not required to control this for first programming and then starting the application/serial loader. I didn't check the reference manual but this is how they all work and probably there is a reference to it, but you may need to read carefully to not miss it.

This means that if you were to use an i.MX RT without internal QSPI flash and boot from the external one it is also possible to force it into ISP mode by short circuiting a QSPI data line at reset because the ROM loader will read it - but not identify a valid a header (due to corrupted data). This trick can't be used when there is an internal one and therefore one has to be more careful not to set eFUSES that don't allow forcing it to ISP mode.

The USB host (memory stick) loader has been used for a number of years in Kinetis based products and since about 3 years (code is compatible above the HS USB interface) in various i.MX RT based products without any (known) issues and so can be considered a proven solution (also documented) for professional needs. It uses the uTasker USB stack with USB-MSD host class plus utFAT, which have also also used in many Kinetis and i.MX RT products for over 10 years and so benefits from reuse of proven modules rather than being a custom project for one purpose. The complete functionality can be verified in VisualStudio since the project emulates the processor, its peripherals (including interrupts and DMA) and also external USB drives, allowing all operations (including custom changes) to easily be thoroughly tested and validated/reviewed for a high level of quality assurance.

Regards

Mark

P.S. The standard HW approach developed for the i.MX RT boot control is described here:
https://www.utasker.com/docs/iMX/uTasker_iMX_WDOG.pdf
Using a KL02 or KL03 it allows for a power cycling watchdog solution with all power sequencing timings plus simple control via a single push button (acting as reset or to control the ISP mode or to disable watchdog operation for debug sessions). The KL02/3 collects statistics of how often it may have had to power cycle the processor and can also be commanded to power down the system for pre-defined periods of time.
The KL03 based version has additional options (not in the document at the moment but in first productive trials) where the KL03 acts as a RTC to the i.MX RT plus 1k battery backed up RAM. Since the RTC in the KL03 is much better than the one in the i.MX RT it achieves much better accuracy with fine compensation and the battery needed can be about 20x smaller than when supplying the i.MX RT (with >=20uA battery backup requirement).
The only problem is that KL03s are almost impossible to obtain at the moment and presently have more than 2 years delivery delay so most people use KL02s (assuming when they can still get hold of them).

P.P.S. The project also includes i.MX RT HS USB programming support via USB-HID host and SWD support via GPIOs and so it is possible to have one i.MX RT that is used to clone FW to other parts via USB (and to the KLs via SWD) in order to achieve high efficiency automatic production programming - in about 10..15s the clone master can automatically complete programming another board ina production environment without needing computer or programming tools. (Basically the clone master acts as the NXP-MCUBootUtility and an SWD debugger/programmer).

[mjbcswitzerland]

P.S. if you implement USB host on your board but the Vbus is switchable you can still program it in USB-HID device mode (i.e. ISP).

[davenadler]

@mjbcswitzerlandThanks again Mark. I reread the "Internal Boot" section: I see if the image header in flash is invalid (or if enabled HAB check fails), loader reverts to serial. So I guess your bootloader image includes the FlexSPI header etc, and could be loaded directly into flash via JLink commander or similar? Or maybe I'll just add the OTG hardware (thanks for the idea of disconnecting VBus at USB connector, but a mistake might be too exciting)...

[mjbcswitzerland]

Dave

Whatever FW is booting it needs the correct flash configuration (header); the serial loader supplies this to match the QSPI flash.

Usually a current limited 5V switch is used for USB host and this usually has an enable input, which can be connected to a GPIO that defaults it (when in HiZ) to the off  state.

Only when the processor is operating and allows the connected USB device to be powered does it enable the switch.

Regards

Mark