iMXRT1060 QSPI size increase

[EmbeddedTech]

Hi,

We are using iMXRT1060 in our board. We replaced the external QSPI flash from 64Mb to 512Mb. After this I am facing the issue of Hard fault error in the SystemInit. May I know what changes I should do in the code when I replace the QSPI flash of bigger size.

Thanks.

[diego_charles]

Hi @EmbeddedTech 

I would recommend checking the Look up table (LUT)  for your new memory. Since I do not know if the bigger size flash uses, for example,  the same R/W OP codes. 

Then, check the linker and the MPU settings. Adapt the linker to fit your new flash and make sure that the MPU initialization covers the flash region. This step may depend on your application and may or not have impact, but is good to consider this. Try running simplest demo available, for example, the led_blinky.

It sounds that you are trying to boot and execute from this memory, let now otherwise. We have the MCUXpresso Secure Provisioning Tool, with this tool you could generate and write  a bootable image.  As another suggestion : build a led blinky sample image , provided by the tool, and check results.

The tool does not consider flash size, but you can customize flash settings. The advantage of this is that you can skip first recommendation of checking the LUT, since the tool generates and writes a "generic" flash configuration, including the LUT. 

That is all I can think for now, if there is another detail to consider, about your new flash, let me know.

I hope this could help you.

Diego

[EmbeddedTech]

Hi @diego_charles,

I already tried flashing the simple iled_blinky example yesterday and had the same Hardfault error. 

In our old board we were using IS25WP064A and now we have replaced with IS25LP512M-JLLE.

I tried the same iled_blinky code in our previous board and it worked ok.

I debugged and found that the Hardfault occured at the instruction in the attached image. The address of the DataTable1 was shown as 0x8800 0ed0.

Whereas in the working old board the address of the DataTable1 was 0xe000 ed88.

In the Startup code, the address loaded to register is 0xE000ED08.

Reset_Handler
CPSID I ; Mask interrupts
LDR R0, =0xE000ED08
LDR R1, =__vector_table
STR R1, [R0]
LDR R2, [R1]
MSR MSP, R2
LDR R0, =SystemInit
BLX R0
CPSIE I ; Unmask interrupts
LDR R0, =__iar_program_start
BX R0

Can you infer something from the above? Why is the address loaded different in two boards?

Thanks for your help in advance.

[diego_charles]

Hi @EmbeddedTech 

Thank you for your patience.

According to my understanding:

The 0xE000ED08 is the VTOR register on the M7 CPU. This is normally used on SDK examples. 

According to the ARM Cortex M7 documentation the register at 0xE000ED88 ( Coprocessor Access Control Register) belongs to the FPU. Below an example.  However, I do not why your application uses this register.

The 0xE000ED08  is used accross SDK examples, so I think this address is ok. 

You let me know that you had failures when running the Led_blinky demo. But what are your modifications to run this demo? Did you used the MCUXpresso Secure Provisioning Tool to generate and load a bootable image or did you modified the XIP folder in your project?

Thank you very much for your patience. Please let me know if you find anything else in the meantime.

Diego

[EmbeddedTech]

Hi @diego_charles ,

Thank you for your reply. I found that the issue with the Hardfault was due to the DQS pin was not left floating in our new hardware. I understand that the DQS pin need to be left floating for proper functioning of the flexspi communication. After I changed the DQS loopback mode to internal and reduce the frequency setting to 60Mhz in the flexspi_nor_config file I was able to run the code successfully.

We have changed out external QSPI flash from 8MB to 64MB. I would like to know what changes I need to do in order to access the full range of Address. Will the current flexspi driver in the sdk work as such for this flash?

Thanks for your help in advance.

[diego_charles]

Hi @EmbeddedTech 

Thank you for letting me know! Yes, DQS pin is particularly important! Congratulations for getting your memory working. 

For now, and generally speaking,  I do not see any adaptation to use your 64 MB flash, except than increasing the size of the flash in the linker file. Beware that mass erase using a debugger an IDE will take now much longer.

I think that FlexSPI driver should work with this memory, but I do not have a way to  guarantee if I  am not able to test , please test it on your side and if you encounter and issue where we can help reach us again. 

All the best, 

Diego

[EmbeddedTech]

Hi @diego_charles,

Thank you for your support. Regarding the 64MB flash, I will test on my side and see if the existing driver works without any issues.

Thanks for your help.

[diego_charles]

Hi @EmbeddedTech 

You are welcome and thanks for letting me know, good luck with the testing!

All the best.

Diego

[EmbeddedTech]

Hi @diego_charles 

I was testing my custom board with 64MB QSPI flash (IS25WP512). After compiling the code with font files of bigger sizes, the total code size in the flash is around 35MB. When I program it using the IAR debugger it takes roughly 20 mins to program the board. On running the code, it takes more than an hour to see the initial GUI screen on the display. It takes long time to execute the APPW_CreatePersistentScreens() in the Appwizard's (GUI tool) MainTask().

What could be the reason for taking such a long time. Since the flash access is beyond 16MB(3 byte addressing range) will it cause this delay? What else I need to take care on the flash access part. 

Your help on this is highly appreciated.

Thanks.

[EmbeddedTech]

Hi @diego_charles,

I am not using j-link for programming. I use the IAR I-jet programmer and use the flashloader that comes along with it. For code size of around 35MB it takes 20 mins to program. Is there any way to reduce the timing or it is normal? For the GUI issue I will raise a separate query.

Thanks for your help in advance.

[diego_charles]

Hi @EmbeddedTech 

Thank you for your reply

As a reference, In the i.MX RT1170 EVKB, the flash memory is also 512  Mb or 64 MBytes, and a mass erase operation using the MCUXpresso IDE or the J-Link commander takes a few minutes, less than 2 approximately,  an write takes much less. 

As you are using IAR and their debug tools, and their flashloader, I would recommend consulting with them, it sounds like the flashloader algo or setup ( QSPI mode or FlexSPI speed) is not optimized for your flash settings. This is just a possibility, a second opinion from them it may help, anyway, if I can help you with something else, do not hesitate to let me know! If you could use our MCUXpresso SPT to program and erase your flash over USB, it may be helpful to have a point of comparison for you.

All the best, 

Diego

[diego_charles]

Hi @EmbeddedTech 

Thank you for your reply and update. 

Oh, 20 min  is quite a long time for programming ! As you may not use a smaller flash, please  consider the speed of the debug probe that you are using. For example, the i.MX RT1060 EVK comes with a LPC43xx that it is running a FW called FreeLink based on CMSIS DAP. According to to AN13206 Modifying Debug Firmware on i.MX RT10xx Boards Featuring An LPC4322-based Debug Probe you can increase by 4 times the program and erase speed by updating LPC43xx FW to the Segger J-Link one. See this application note. Now that we are talking about J-Link, you can optimize the flashloader speed, see this application note :  AN13567
Optimizing Flashloader Download Speed on RT Platform with JLink  I have not tried this already, but it may help, so save some headaches for waiting such long time. 

Now with regarding the GUI issue, It sounds that your  GUI algo is not optimized for your flash size, I cannot tell why you are seeing such behavior, but feel free to create another  dedicated post with details on this, me or other of my colleagues could take a look on this. 

Diego