cancel
Showing results for 
Search instead for 
Did you mean: 

FileX + LevelX Log Circular Buffer Implementation STM32U585

PJose.4
Senior

Hi Everyone
Greetings

We are using an STM32U585 MCU and need to maintain a log of about 200 KB using FileX. Once the 200 KB storage is full, I don’t want LevelX to reclaim the entire file and erase it. Instead, I need the log to behave like a circular buffer, where only the oldest block of log data is erased and overwritten with new data. How this requirement can be achieved. For this requirement how much size shall be allocated  by fileX(im using an external flash of 8MB).

Thanks and Regards

Philip

3 REPLIES 3
MFARH.1
ST Employee

Hello @PJose.4 ,

To implement a 200 KB log functioning as a circular buffer with FileX on the STM32U585:

- FileX does not natively support circular buffer functionality. You need to handle this at the application level by writing to a fixed-size file and wrapping around to the beginning once the end is reached, thereby overwriting the oldest data.

- LevelX manages the physical flash memory (erasing, wear leveling) but does not delete files. Your circular buffer management will work seamlessly alongside LevelX.

Regarding size allocation, it is advisable to allocate a partition slightly larger than 200 KB, for example between 256 KB and 512 KB, to accommodate both the data and the file system overhead.

BR,

Maher

Hi @MFARH.1 

Greetings
Thanks for your reply
1. regarding the previous reply we are implementing circular buffers from our application level. We have implemented 2 100 kb files for storage of the logs and when the second one gets filled, first one gets erased and vice versa to replicate the circular buffer method.

2. Free sectors are calculated during media initialization. As logs are written to flash, the number of free sectors decreases. If the available free space drops below two blocks, a reclaim operation is triggered. During this reclaim, the first block will be erased, leading to the loss of driver initialization data and log entries. How can this issue be avoided?

3. It’s not feasible to allocate between 256 KB and 500 KB for a 200 KB file because writing each log entry reduces free sectors by 64 or 96 sectors(sector size 512) due to wear levelling. In this case, what would be the recommended partition size  and how prevent reclaim and data loss?

Thanks for the continued support
BR
Philip

MFARH.1
ST Employee

Hello  @PJose.4 

 

To prevent data loss during the reclaim operation, several solutions can be considered:

  • Reserve a specific area of the partition for critical data that will not be erased automatically.
  • Additionally, periodically backing up critical data to another memory (such as external memory) allows restoring this data in case it is erased during reclaim.

Regarding partition size, it is recommended to allocate significantly more space than the actual data size (for example, more than 500 KB for a 200 KB buffer) to provide sufficient margin for wear leveling and reduce the frequency of reclaim operations. Furthermore, optimizing the size of write operations and implementing over-provisioning (reserved space unused by the application) helps limit fragmentation, data loss, and extends the lifespan of the flash memory.

 

Regards,

Maher