XIP from QSPI NOR Flash on MIMXRT1062

[nsi]

Hello,

I am currently working on a new custom board using MIMXRT1062DVJ6B and MX25V1635FZUI as the QSPI nor flash for XIP mode. I have been able to run the code when using the "Link application to RAM" setting from MCUXpressoIDE. I managed to have "flexpi_nor_polling_transfer" example, by changing the flexSPI clock speed and the erase sector command.

However, I didn't manage to run code from XIP. When I try to debug from MCUXpresso, the debugger does not get to the main breakpoint and just says that the thread is running. I am assuming that it is related to the fuse configuration or the XIP parameters in code but can't find a way to be sure.  

Additional information:

- The file evkmimxrt1060_flexspi_flexspi_nor_config has been changed to have serialClkFreq to kFlexSpiSerialClk_80MHz and the flash size to 16MB. The lookupTable has been checked.

- We are using the GPIO to configure BOOT_MODE, BOOT_CFG1 and BOOT_CFG2.

- We use a JLink BASE Compact with SWD to flash the board.

1. Do I need to program the fuses to be able to run from XIP with a speed lower than 100 MHz or is the correct speed discovered automatically ? in the fusemap I see 0x6E0[3:1] (BOOT_CONFIG_ MISC) as a way to configure xSPI FLASH Frequency which is set to 0 if I understood correctly

2. Do I need to change the QE bit of the flash at everyboot to switch it to QSPI ? How would i do that when I cannot start the code ?

3. Are there other settings I should look into ?

Thanks,

Nicolas

[mjbcswitzerland]

Hi

If you have the MODE 00 and Mode 01 set to not boot into the ROM loader you should find that the processor is reading the configuration from the QSPI flash after it resets (look at its CS line with a scope of a logic analyser).
There are some GPIOs that define some details about the Flash type (when eFUSEs are at default)
BOOT_CFG1[7:0] and
BOOT_CFG2[3:0]
which need to be checked - if they default to '0' there will be no problems. Otherwise you can blow an eFuse to disable them being used.

Some QSPI flash devices have different variants that either have the QE bit set or not - it is best to be sure to purchase the correct ones that have this configured since quad mode is what is used by default.

In case you have the wrong parts (without QE mode set) you can program the mode - either by removing the chip and programming it in an appropriate programmer or by loading a FW to the processor's RAM (eg. via SWD or SDP) that does it. The QE mode is typically non-volatile and it may also be OTP, so this is usually only needed once.

Regards

Mark

PS. Check out the uTasker project for the 1062 for complete solutions to application developments and manufacturing tools (eg.):
https://www.utasker.com/docs/iMX/uTasker_iMX_WDOG.pdf
https://www.utasker.com/docs/iMX/uTasker_iMX-RT-Programmer.pdf
For available stock of Kinetis and i.MX RT1062 see here: https://www.utasker.com/Shop/semi.html

[nsi]

Hi, thank you for your reply

We are using boot mode 0b10 for testing, should i try it with boot mode 00 or 01 too ?

When powering up the board, I can see processor reading from the QSPI (see attached image). Note that the clock is at 33.33MHz for all transfers in this screenshot except for the last one when it goes to 2.86MHz.

From what I understood of our flash, the BOOT_CFG1 and BOOT_CFG2 registers should be at 0. I have tried enabling xSPI Flash Auto Probe during my attempts (screenshot above is with BOOT_CFG1=0x1 and BOOT_CFG2=0x0).

Our flash does not have the QE bit set by default but I have enabled it (and checked after a full reboot) using the flexpi_nor_polling_transfer example.

Regarding μTasker, does it requires a connection to the processor other than the standard SWD ?

Thank you for your help,

Nicolas

[mjbcswitzerland]

Hi

These are the only two ISP settings that re of use in the QSPI flash case:

Normal Boot (for QSPI flash): Mode 00 = '0' / Mode 01 = '1'
ISP Boot: Mode 00 = '1' / Mode 01 = '0'

The uTasker factory programming support uses HS USB (ISP) as standard. If USB is not used by the application it can still be connected via bed of nails on the USB+ and USB-lines.
In addition is supports programming via SWD (from another i.MX RT) although I have in fact only used it to program Kinetis parts with until now (since HS USB is the preferred i.MX RT method).

Regards

Mark

[nsi]

Thanks, I will look into µTasker for factory programming then.

For now, I will focus on setting up everything for debugging as we need to start testing our hardware.

[diego_charles · Accepted solution]

Hi @nsi 

I have an alternative to aid your troubleshooting. 

Could you try to use our MCUXpresso Secure Provisioning tool? This tool requires to stablish communication using the pins that the bootROM support,, they are for LPUART1 or USB1, also you need  to change the boot mode pins to serial downloader mode 0b01.

The tool lests you to test with ease the XIP/FCB configuration for your memory and then convert it to a FCB.  See below a very general image describing this process. 

Once your FCB config is successfull, we can use the Convert to FCB option.

We can use the created FCB to either:

A) Generante a bootloable image with the tool, we can see steps later.

B) Do reverse engineering and make your flash config structure to look like the FCB the tool generated.

The QE bit is expected to be burn only once. The boot mode config pins as 0b10 is okay, this should be internal boot mode, so the bootROM attemps to boot from the external flash. The boot config pins  should be set to zero for the default config.  

All the best, 

Diego

[nsi]

Thank you very much, I managed to start code from XIP using the MCUXpresso Secure Provisioning tool !

Following the steps you provided, I generated the FCB, modified the axf generated using MCUXpresso IDE and used MCUXpresso Secure Provisioning tool to write the image. That image properly started when I rebooted the board after going back to boot mode 0b10.

Now I would haven't been able to configure theMCUXpresso IDE to generate the correct image right away. Ideally, for development I would need to be able to write the correct image using our JLINK Base Compact while debugging.

Is there a way to include the generated FCB to another project (once board testing is done i would like to work outside MCUXpresso IDE) ?

Thank you for your help,

Nicolas

[diego_charles]

Hi @nsi 

Please take a look at this article from one of my colleagues  it is very handy. 

Recommeding this because he provides a script  (fcbConverter.py) that convertes the binary fcb into code i.MX RT FLEXSPI booting guide 

All the best, 

Diego

[diego_charles]

Hi Nicolas,

I am glad that our SPT tool helped you!

Regarding > Is there a way to include the generated FCB to another project (once board testing is done i would like to work outside MCUXpresso IDE) ?

The FCB bin  that the tool generates should be independent to the IDE. I did not completely understood the question, could you detail further?

Thank you, 

Diego

[nsi]

I guess my question is : How would I identify what's wrong with my IDE setup ?

Currently, I'm working with MCUXpresso IDE for the basic testing and for using the config tools. For the actual developement I'm using the gcc-arm SDK.

I haven't been able to run any code generated by those 2 environments from XIP, they only run when I link them to RAM.

I have looked at the hex file generated from the arm-gcc version and manually compared the first 512 bytes to the FCB generated by SPT (I don’t know any tool that would allow me to repeat the operation with the axf generated with MCUXpresso IDE). They are identical. However, when I load the hex file generated by arm-gcc for debugging it doesn't run.

Going through the Serial Downloader boot mode requires moving resistors around on the board so it isn't really realistic to do it every time I want to load code.

[nsi]

Alright, thanks to the SPT I managed to identify what was wrong with the arm-gcc SDK: the DCD wasn't properly included since I didn't have the XIP_BOOT_HEADER_DCD_ENABLE flag set up. I am still confused as to why that was working on the dev board without it but at least I can keep going.

However, I haven't been able to understand why the axf generated by MCUXpresso IDE is not working.

I'm accepting @diego_charles's answer as the solution as it got me on the right track to solving my issue. Thank you for your help!