File system in QSPI flash

[gauravmore]

Hi,

We are using LPC4367 tri core controller for our product development. We are using QSPI interface in the development.  We have interface  W25Q128JVFIM with the LPC4367  controller. 

We are looking for File system to be implemented in the SPI Flash interface peripherals. Is there any such sample code or a reference for File system over QSPI flash will be helpful.

BR,

Gaurav More

[frank_m]

There is a FatFS implementation for microcontrollers, and I believe it is even optional part of the MCUxpresso SDK for most controllers.

But that would only be an advantage for transferring files either with your project (as part of the build/link process or the flashing tool), or for file access to the target at runtime.

You could as well create a simple ad-hoc file system, with start address, size, and any other parameter you need for administration. Like checksum, or code start address.

[gauravmore]

Hi Frank,

Thanks for the response, 

I check with the other forums regarding the file system implementation over QSPI flash , there I found that there will be problem since the time for block erase is around 100 to 300 msec or more , also block size is 64KB and sector size is 4096. So implementing the same will block the controllers execution w.r.t other module even though the time to write is faster in QSPI flash,

So instead can we get the sample code or any reference document for porting the file system on SDRAM. I am using 8MB SDRAM in our development. with reference to the below link do we have the same for LPC controllers?

https://stm32f4-discovery.net/2015/05/fatfs-library-extended-for-sdram/

Can we get similar code with file system implementation on SDRAM in MCU Xpresso would be very helpful.

BR

Gaurav More

[frank_m]

> I check with the other forums regarding the file system implementation over QSPI flash , there I found that there will be problem since the time for block erase is around 100 to 300 msec or more , also block size is 64KB and sector size is 4096.

Apart from varying blocksizes, this is an inherent property of flash. Program and erase takes quite a long time, erase works only blockwise, and the whole bank is blocked during this operations.

I don't know about the requirements for you applications,  i.e. effects on realtime tasks or requirements. With QSPI flash, you can at least still execute code from main flash.

Perhaps you could consider a RAM mirror of a flash file system, and synchronize occasionally. Such RAM file system are widespread with application processors (like Cortex A) with relatively large RAM, and code exacution mainly from RAM. Less so with microcontrollers, because of the very limited internal RAM sizes.

I think the code presented in the link should be portable to LPC and MCUXpresso. I think there is no restriction to one file system object in the FatFS code.

You would need to check how this code managed to differ between both objects and respective low-level functions (i.e. both drivers are enabled). Implementation of the RAM-based low-level driver functionality should not be a problem.

[gauravmore]

Hi Frank,

I got your point and I trying to get the source code for the same in order to port and implement the same in MCU Xpresso.

Will check regarding the same and revert with the result , also expect and input from your side w.r.t the source code if you get the same for MCU Xpresso.

BR

Gaurav More

[frank_m]

I guess I can't contribute much in regard to a RAM file system, I never tried that in any of my MCU projects. Reason is, as mentioned, there was always a lack of RAM space, never an abundance. And second, one of the main incentives for a file system is persistence, which is not given with a RAM-FS.

The OM13098 is an exception here, with 8MB of SDRAM.

I use it for a kind of event recorder application. Data are gathered in realtime for a specified time and stored in SDRAM, and written to SD card afterwards. With about 100k sum sampling rate, this is sufficient for my application. Not worth the hassle of implementing overlapping FS writes with multiple buffers / pipelines to achieve sufficient FS throughput.

Just as disclaimer, this is a private project of mine, as all my other projects with LPC MCUs.I am not NXP staff, nor in any way affiliated with NXP.

[gauravmore]

Hi Frank,

Thanks for your response,

As you mentioned that you have used SDRAM for storing the events then can you share the code snippet of yours not the complete project since that will also help me for development of the SDRAM interface.

BR,

Gaurav More

[frank_m]

This is very simple.

I placed a normal array in the SDRAM area, and stored individual values there. This is simple C data management. The same way for writing to SD card via FatFS.

The SDRAM initialisation is the other significant part, which I took from the respective SDK example. Just don't forget to merge the required code in pinmux.c, to initialise the physical SDRAM driver pins.

Basically, I collated the ADC example, the SDRAM example and the FatFS example, extended and adapted the code.