i.MX RT 1062, QE Bit in ext SPI Flash, devices do not boot. Best practices to config external NV

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT 1062, QE Bit in ext SPI Flash, devices do not boot. Best practices to config external NV

Jump to solution
2,023 Views
DavidClus
Contributor I

Dear all,

after some extensive investigation we could fix/workaround our problem, but we don't fully understand why. Based on our experience, we assume that we did not fix the root cause, and trouble will catch us again....

Let me try to shortly sketch the situation:

We have a design based on a i.MX RT 1064 device with internal flash. Due to the current supply situation we needed to switch to a i.MX RT 1062 device with an external SPI Flash.

We have chosen an ISSI IS25LP064A-JBLE serial flash.

 

In a first step, we faced the situation, that the devices didn’t boot into our application. After burning the  BT_FUSE_SEL Fuse with the NXP MCU Boot utility things seemed to work, at least most of the time.

Some times after several chip erases during development, our devices stop booting, even though the BT_FUSE_SEL Fuse was set.

In order to move towards production, and have the fuse automatically burned by the production equipment, we switched form NXP MCU Boot utility to sdphost and blhost utilities.

We found some other posts here, with almost the same problem, and came to the point, that we need to adjust the Quad Mode Enable (QE) bit in the NV section in the external SPI Flash.

Re-burning already burned BT_FUSE_SEL Fuses with NXP MCU Boot Utility repairs non booting devices.
Re-burning already burned BT_FUSE_SEL Fuses with sdphost and blhost utilities DID NOT repair non booting devices.

Looking for the difference, we found that NXP MCU Boot utility also adjusts the NV section in the external SPI Flash. But what is really odd here:

This is what is necessary, in order to let the devices boot correctly:

blhost -t 5242000 -p COM4,115200 -- fill-memory 538976256 4 3221225479 word
//                                              0x20202000  0xC0000007
blhost -t 5242000 -p COM4,115200 -- fill-memory 538976260 4 0 word
//                                              0x20202004
blhost -t 50000 -p COM4,115200 -- configure-memory 9 538976256
//                                                   0x20202000

Q1: Why do we have to set the Quad Mode Enable Setting to 0 == Not Configure

DavidClus_1-1632228891255.png

 

We had expected, that the QE Bit 6 shall be set in the external SPI Flash?

The other thing,

Q2: What is the best practice regarding those NV configurations in external SPI.
Is it to configure it during production and never touch it again? Or reconfiguring it on every device start? We found one application note of a flash manufacturer that gives a hint, not to reconfigure it every time, due to write cycle limitations.

Sorry for the lengthy post, I tried to compress some weeks of investigations.


Looking forward to your response

David

 

0 Kudos
1 Solution
1,944 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thanks for your reply.
1) How can we prepare our application image in a way, that the bootloader first probes the QE bit and re adjusts it when neccessary as it is done in the above screenshots. That would be the desired bevaviour from our point of view.
-- From my experience, we usually recommend the customer to enable the QE bit during manufacturing production, as the value of the QE bit usually won't change without manual manipulating.
Actually, it's impossible to readjust QE bit via either DCD or fsl_flexspi_nor_boot.c.
However, It's able to write 1 to QE bit per boot-up via configuring the fsl_flexspi_nor_boot.c, but it's not a good idea due to write cycle limitation.
Maybe you can contact the Flash manufacturer for some suggestions.
Have a great day.
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

View solution in original post

4 Replies
2,003 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Why do we have to set the Quad Mode Enable Setting to 0 == Not Configure?
-- Firstly, the QE is not necessary to set 1 actually, however, we almost set the QE to 1 in the real design, as we need to use the four data line to increase the efficiency of fetching the code from the QSPI flash and the code executing performance is terrible when fetching the code via the standard SPI port.
2) What is the best practice regarding those NV configurations in external SPI.
-- In the application note, it lists the steps of programming the QSPI flash.
In Step 7, the executing the following command to generate an sb file that not only contains the application image but also contains the configuration information of the QSPI flash, you can find the configuration information in the /program_flexspinor_image_qspinor.bd file (just like below figure shows).

 

elftosb.exe -f kinetis -V -c ../../bd_file/imx10xx/program_flexspinor_image_qspinor.bd -o boot_image.sb
ivt_flexspi_nor_hello_world_nopadding.bin

 

jeremyzhou_0-1632281037884.png

Have a great day.
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
1,959 Views
DavidClus
Contributor I

Dear Jeremy,

thank you for your reply, It brings at least a bit more light into the dark.

We are well aware that QE bit needs to be set to achieve performance.

One comment in your posted configuration file answered our question Q1:

DavidClus_0-1632911156978.png

 

0 does NOT mean not to set QE bit, but to rely on automatic detection of the flash and parsing its JEDEC information and set QE according to it.

Performing the the sequence:

blhost -t 5242000 -p COM4,115200 -- fill-memory 538976256 4 3221225479 word
// 0x20202000 0xC0000007
blhost -t 5242000 -p COM4,115200 -- fill-memory 538976260 4 0 word
// 0x20202004
blhost -t 50000 -p COM4,115200 -- configure-memory 9 538976256
// 0x20202000

with an already correctly configured SPI Flash, results only in a verify sequence, that checks if the QE bit is set:

DavidClus_1-1632911700636.png

 

When performing the same sequence with a non configured SPI Flash, the verify fails and the QE bit is written again:

DavidClus_2-1632911813162.png


So Q1 is answered!

Regarding the best practice to set it (Q2), we are still not fully convinced to have the final solution / understanding.

Currently we write the QE bit once during production. The flash manufactures don't want us to rewrite the BIT during every boot section, the bit should be non volatile.

Nevertheless we figured out, that looping chip erase / program cycles / verify cycles sometimes result in deleted QE bits.

We also don't want to serially bootstrap the devices during production.

Currently we see, that two configuration blocks are appended to the application image with the toolchain.

One is the DCD block, the other thing is the spi flash config block, that can be adjusted with xip\fsl_flexspi_nor_boot.c (?).

Just let me refine our Question Q2: How can we prepare our application image in a way, that the bootloader first probes the QE bit and re adjusts it when neccessary as it is done in the above screenshots. That would be the desired bevaviour from our point of view.

Looking forward to your response

Kind Regards

David

 

 

 

0 Kudos
1,945 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thanks for your reply.
1) How can we prepare our application image in a way, that the bootloader first probes the QE bit and re adjusts it when neccessary as it is done in the above screenshots. That would be the desired bevaviour from our point of view.
-- From my experience, we usually recommend the customer to enable the QE bit during manufacturing production, as the value of the QE bit usually won't change without manual manipulating.
Actually, it's impossible to readjust QE bit via either DCD or fsl_flexspi_nor_boot.c.
However, It's able to write 1 to QE bit per boot-up via configuring the fsl_flexspi_nor_boot.c, but it's not a good idea due to write cycle limitation.
Maybe you can contact the Flash manufacturer for some suggestions.
Have a great day.
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

1,938 Views
DavidClus
Contributor I

Hello Jeremy,

perfect. So we finally understood the behavior and configure the QE bit in your recommended way.

I'll try to contact the flash manufacturer and our tool manufacturer, to hopefully figure out, why the QE bit is sporadically reset, when cycling through chip erase / program iterations.

 

Thank you!

Kind Regards

David

 

0 Kudos