IMXRT1064 CAN Bootloader

[tisch]

Hi everyone,

I want to port a existing and working CANopen-Bootloader to NXP IMXRT1064. The Bootloader works like this: It sits in the normal flash of a small microcontroller and on top comes the application which the bootloader can modify at runtime.

But with the IMXRT1064 it is very different in comparison to my little microcontroller. It has a 4MB QSPI Flash integrated directly into the package, connected to FlexSPI2.

I've already experiemented with the example bootloader projects from the NXP SDK, flashloader and mcuboot, and also with the nor_flash-example but I think I have fundamental misunderstanding of how the application is running over QSPI flash together with a bootloader.

My first question is where do I need to store my CAN-bootloader? Does it need to sit in QSPI-Flash or maybe ITCM or somewhere else? Where should i store it?

My second question is if the bootloader is programmed into QSPI-Flash (0x70000000), can the bootloader run and modify the upper ranges of the QSPI-Flash (e.g. 0x70020000) where the application would be stored? How is a write access via internal FlexSPI2 even possible while the processor needs to load instructions to run the bootloader?

Thank you.

[mayliu1 · Accepted solution]

Hi  @tisch ,

Thank you so much for your interest in our products and for using our community.

Q1: My first question is where do I need to store my CAN-bootloader? Does it need to sit in QSPI-Flash or maybe ITCM or somewhere else? Where should i store it?

A1:  For i.MX RT1064, the bootloader image is normally stored in the internal 4 MB SIP QSPI flash connected to FlexSPI2, because this is the primary boot device for RT1064 .

RT1064 supports both XIP and non-XIP boot from Serial NOR flash:

an XIP image executes directly from the FlexSPI address space, while a non-XIP image is copied to internal RAM for execution .

So the bootloader is typically stored in QSPI flash,  OCRAM/ITCM are execution locations , not the normal boot storage defined by the ROM boot flow.

Q2:My second question is if the bootloader is programmed into QSPI-Flash (0x70000000), can the bootloader run and modify the upper ranges of the QSPI-Flash (e.g. 0x70020000) where the application would be stored? How is a write access via internal FlexSPI2 even possible while the processor needs to load instructions to run the bootloader?

A2: Yes, a bootloader stored in the internal QSPI flash can update a higher flash region used for the application, but it must not continue executing from that same flash while erase/program is in progress. 

RT1064 provides ROM FlexSPI NOR APIs such as init , program , erase , read , and update_lut for in-application flash operations. During flash erase/program, the update routine should execute from internal RAM，and the application must ensure there are no other flash accesses during the operation， otherwise behavior is unpredictable.

I suggest you can refer to this link below:

How to use the RT1064 on-chip flash as NVM

Best Regards

May

[tisch]

Hi May,
your answer and the link to change the flexspi_nor_example from flexspi to flexspi2 helped a lot. I was able to write the application into the flash and startup the application.
Thank you very much.

[mayliu1]

Thanks for your updated information and sharing.

If you meet any issue in the future, welcome to create the new question post.