Update FlexSPI LUT before XIP from FlexSPI A?

[bw1]

Background:
We have a custom target using the RT1062 - We are eXecuting In Place from QSPI NOR on FlexSPIA and would like to use FlexSPIB for data storage. Trying to update the LUT from code does not work (running out of FlexSPIA), generates Bus Faults. That is expected right?
I thought that the LUT we load into FlexSPIA (0x6000_0080) for boot would be copied by the BootROM into the micro's internal LUT (0x402A_8200), but that does not appear to be the case. 

Questions:
1) If possible, what is the best method to get the micro's internal LUT updated at boot, before XIP from FlexSPIA?
2) The Flexspi NOR Polling Transfer example in the SDK creates a custom LUT, but does not use custom sequence enable or custom LUT sequences in the config - Is this not necessary since it is not used at boot?
3) Is there some other option to update LUT while XIP from FlexSPI A, besides executing out of RAM?

[richy_ye]

pengwang‌, can you give comment for customer's requirements? Thanks!

[wayne_wang]

RT1060 also provide the other way to update LUT by ROM api, it provide the api function for customer to re-initialize flexspi nor flash by calling api function without allocating the function to RAM, please refer to attached code.

also it give one example to initialize FlexSPI not flash as below:
status = flexspi_nor_flash_init(FLASH_INSTANCE, &flashConfig);

it is available to update new LUT by modifying "flashConfig".

also I have ever try to update the LUT by allocating the code to RAM, it can work well, no issue happen, and one customer has got production.

[bw1]

Upon further investigation, I believe the RAM function is updating the LUT with the values I programmed.  I believe the fact that I changed the read command in the LUT is causing the XIP from Flash A to fail, resulting in the fus failure.  If I do not change this LUT entry (the first one in the table) then I do not see the bus fault failure anymore.  However, I do have problems trying to execute other commands for FlexSpi Flash B. 

This brings up some questions that I have not been able to answer reading the reference manual. Hopefully you can clarify a few things.

1) The values loaded into the LUT by the micro's ROM do not match the ones I load as part of the boot config. So I take it they are some default values that come from internal ROM?  I thought possibly they were being read from the QSPI Flash A, but when I view the LUT in the debugger after boot several of the commands do not match valid ones for this QSPI device.

2) Does the Flexspi A when XIP only use the default LUT sequences?  

3) How do I not corrupt the XIP process when I am updating the LUT for the commands needed to work with FlexSPI B?  For instance, I cannot enter the disable mode (set the MCR0[MDIS] bit) without a failure. 
 

[melissa_hunter]

Hi Brad,

I'm going to try and help. The thread has gotten to be long, so I'm going to back up a bit and try to give some background info that I think will make things a bit clearer.

The ROM will copy the read entry from the LUT portion of the FCB into the FlexSPI controller's LUT. So on a normal boot you should only see a read command used for executing in place copied into the FlexSPI LUT (command 0 by default). It is important that the read command is left untouched as this is what is used to read code uses AHB bus accesses.

If you absolutely have to change the index used for the read command, then you have to reconfigure the ARDSEQID and ARDSEQNUM in the appropriate FLEXSPI_FLSHnxCR2 register when reconfiguring the LUT (with all of the code handling this in RAM).

If you need to add additional commands into the LUT, then you need to use code executing from the RAM to update the LUT. To update the LUT you will temporarily corrupt the XIP process, so you need to make sure there are no FlexSPI accesses happening while the controller is being reconfigured. After the reconfiguration is complete, then you can re-enable the FlexSPI (clear MCR0[MDIS]) and jump back to executing in place.

Hope this helps,

Melissa

[hafeesmohammed]

Hi NXP team,

In our current project, we are using i.MXRT and two HyperBus devices (RAM and Flash). We are able to modify the LUT and populate additional commands for HyperRAM from a code which runs out of Internal DTCRAM. This code is created using "plain load image" option in MCU Expresso (thanks to this link ->A way to create a binary that is copied to RAM from the ROM bootloader in RT1050 ). With this, both devices (RAM & FLASH) are accessible.

In order to optimize the drive strength , we want to configure the internal register(VCR) of HyperFlash (Cypress S26KL256S) and HyperRAM.

Can you give some idea on how to configure the internal registers of HyperFlash/RAM?

I am referring the example code (\SDK_2.4.2_EVKB-IMXRT1050\boards\evkbimxrt1050\driver_examples\flexspi\hyper_flash\polling_transfer). Do I need to add any LUT entries to in this example to read/write registers? Or can I do this without any extra LUT entries?

Regards,

Hafees

[bw1]

Thanks

[art]

Q1. If possible, what is the best method to get the micro's internal LUT updated at boot, before XIP from FlexSPIA?

A1. There is no way to do that.

Q2. The Flexspi NOR Polling Transfer example in the SDK creates a custom LUT, but does not use custom sequence enable or custom LUT sequences in the config - Is this not necessary since it is not used at boot?

A2. Yes, your understanding is correct.

Q3. Is there some other option to update LUT while XIP from FlexSPI A, besides executing out of RAM?

A3. There is no way to do that other than executing the LUT updating code from RAM.

Have a great day,
Artur

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

[bw1]

I created a Ram function using IAR's "__ramfunc" keyword for updating the micro's LUT.  It executes OK, and updates the LUT properly.  However, some type of bus fault occurs on one of the next source statements upon returning from the RAM function.  It is typically an "unaligned access error" or an invalid instruction.  

Is there something else beside disabling interrupts that needs to be done around this ram update function?

The D-Cache is disabled earlier in the configuration process. I tried disabling I-Cache as well, but that didn't make a difference.