Using external flash (MX66UW1G45G) via XSPI as FileX backend on STM32U5G9J-DK2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-10 9:52 PM
Hi all,
I’m trying to use the external NOR flash (MX66UW1G45G) on the STM32U5G9J-DK2 board as the storage backend for a FAT filesystem using FileX.
I came across the example “Fx_NoR_Write_Read_File” from STM32CubeIDE (STM32U5G9J-DK2 package), which appears to be doing exactly this — creating a FAT filesystem using FileX and LevelX on the external NOR via XSPI. However, it’s .ioc file is missing, so I can’t see how the XSPI interface and pins are configured.
I built and flashed the example as-is, but the fx_media_format() call returns FX_IO_ERROR (0x90 in Hex and 144 in decimal).
Could someone please guide me on the correct steps to:
- How to properly configure XSPI for the MX66UW1G45G in CubeIDE.
- The correct steps to use FileX and LevelX with external NOR flash as the filesystem backend.
Thanks in advance!
Solved! Go to Solution.
- Labels:
-
FileX
-
LevelX
-
STM32U5 series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-17 8:26 AM
Hello @Gowri_M,
The application "Fx_NoR_Write_Read_File" in STM32CubeU5 works correctly.
I recommend following the steps provided in the Readme file: Link
Also, you may find this post helpful: STM32H7 Write to QSPI using Filex and Levelx. Issue at fx_media_format
I hope my answer has helped you. When your question is answered, please select this topic as the solution that answered you, as it will help others find that answer faster.
Thanks for your contribution.
Dor_RH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-16 3:46 AM
Hello @Gowri_M,
I recommend checking out this post: Request for .ioc File of Fx_NoR_Write_Read_FileExample for STM32U5G9J-DK2
"As noted in the Release Notes under Known Limitations, this application is currently provided without an .ioc file. This limitation will be fixed soon in the next release of STM32CubeU5"
I hope my answer has helped you. When your question is answered, please select this topic as the solution that answered you, as it will help others find that answer faster.
Thanks for your contribution.
Dor_RH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-16 4:37 AM
Hello @Gowri_M,
You may find these articles helpful: Introduction to FILEX and Introduction to LEVELX
Both resources could provide valuable insights for your application.
Thanks for your contribution.
Dor_RH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-16 9:40 PM
Hello @Dor_RH
Thank you for the clarification on the .ioc file.
However, the issue with fx_media_format() returning FX_IO_ERROR still persist - any guidance on this would be appreciated.
Thanks!
Gowri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-17 8:26 AM
Hello @Gowri_M,
The application "Fx_NoR_Write_Read_File" in STM32CubeU5 works correctly.
I recommend following the steps provided in the Readme file: Link
Also, you may find this post helpful: STM32H7 Write to QSPI using Filex and Levelx. Issue at fx_media_format
I hope my answer has helped you. When your question is answered, please select this topic as the solution that answered you, as it will help others find that answer faster.
Thanks for your contribution.
Dor_RH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-06-17 8:36 AM
The Sector (Erase) Size on the MX66UW1G45G is 4KB, this should be the sector size you use on most QSPI/XSPI NOR Flash devices for a FAT file system, otherwise deblocking will be an absolute nightmare.
The Page Size (Write) is 256 bytes, so will take 16 separate (aligned) operations to write a 4KB sector that's previously been erased.
To understand where upper level errors come from it might be instructive to output diagnostic / telemetry data from the lower / block level interactions, ie for FATFS implementation how DISKIO interacts with the BSP/CSP code. Likely equivalents for FILEX
Up vote any posts that you find helpful, it shows what's working..
