iMXRT1176 ROM API: trouble with QSPI flash on FlexSPI2, secondary pin group

[Mysterion]

Hi,

we designed a custom board with iMXRT1176 MCU and a IS25WP128 serial flash (same family as used on the RT1170 eval board, just less memory) connected to port A via the secondary pin group of FlexSPI2.

When trying to upload the hello_world application included in the SDK 2.10.1 via IAR Embedded Workbench V9.30.1, the upload fails (of course I modified it appropriately in order to be loaded to FlexSPI2, and provide suitable option bytes).

In parallel, I've done a software application running in RAM, which is able to read and write the flash, and map the flash content via AHB. Exen QPI DDR mode at maximum speed works without any problem, so I can rule out issues related to our custom board. Reading the flash content after the failed upload attempt with my app shows an alternating pattern of pages programmed and left blank.

I've compared the electrical signals between the RT1170 eval board (using FlexSPI, primary pin group) and our custom made board. On the eval board, the programming sequence for each page runs as expected:

- transmit write enable command

- transmit page program command

- poll the status register until WIP goes to 0

- repeat preceding steps for next page

On our custom board:

- transmit write enable command

- transmit page program command

- read the status register just once. Although WIP ist still 1, the flash loader continues with the next page, ignoring the flash is still busy

In consequence, each second page program command is ignored by the flash, leading to the alternating pattern I observe. Please find oscilloscope screenshots and the decoded SPI traffic for both boards attached!

As far as I've tracked down the problem, the ROM API's wait_busy() function - at least in this setup - returns OK, independently from the flash status. So I patched the flash loader by inserting a dull but adequate delay after each page program operation. Now the flash exactly contains the data it should contain. However the flash loader still aborts with a checksum error.

For me, this looks like the ROM API does operate FlexSPI2, but while performing write operations flawlessly, it does ignore any data that is read from FlexSPI2, which would explain the WIP flag being ignored, and the checksum error (although the flash contains the correct data).

Can you confirm this behavior, or is there anything I could have missed from my side? Actually, uploading to flash via the IDE should work out of the box, independently from the FlexSPI instance used. No issues on uploading to the eval board's flash at all. The only relevant differences are FlexSPI2 and the secondary pin group.

I also examined the IAR flash loader, which is mostly a wrapper for the ROM API, so it sould be alright.

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you can try to update the flashloader driver via the post.
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.
-------------------------------------------------------------------------------

[Mysterion]

Dear Jeremy,

unfortunately, the link is about the J-Link debugger. We're using IAR i-jet.

Surely, I could do a custom flash loader based on my application, which is able to read and write the flash, not relying on the ROM API. But even then: our intention is booting from the flash; so if this is a ROM API issue with FlexSPI2/secondary pin group, we most likely won't be able to boot from the flash.

The chip errata don't mention anything about that, but I couldn't find any problem in hardware or in the actual IAR flash loader, which in fact is just a thin wrapper for the ROM API.

[jeremyzhou]

Hi,
Thanks for your reply.
Firstly, I consider the hardware board is good, and I guess the weird phenomenon is related to the modified flashloader driver of the IAR, next, to test boot from the FlexSPI2, you can use the tool to program the appropriate image to the QSPI for the testing.
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.
-------------------------------------------------------------------------------