Solved! Go to 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
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
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
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
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.
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
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
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
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
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.
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!