Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[threadx-users] Issue with LevelX Wear-Leveling on STM32H563 with SPI-Serial-Flash

Dear community,

I’m experiencing an issue with the LevelX wear-leveling, which I have implemented on an STM32H563 in conjunction with a SPI-Serial-Flash (using a custom driver).

When the flash is fully erased, everything seems to work well for a while. However, after some time during operation, the FileX Root Directory becomes inconsistent. It appears that this issue is
related to LevelX, as there seem to be two valid sector mappings for sector 4. This results in finding a 0xF01C on the first search and a 0x501C on the second search, without any write operations in
between.

To be honest, I am currently testing this for a product with several power outages in between, but I thought LevelX was supposed to handle this.

Additionally, it seems that consecutive writes to the Root Directory only advance the mapping for the second entry. However, after every system reboot, the root sector is still found at 0xF01C.

I have reviewed the code, and it seems a lot of care has been taken to avoid creating two "valid" mappings simultaneously, even in the event of power outages. Is there any insight into how this could
have occurred?

I also encountered a "LX_SYSTEM_INVALID_FORMAT" error once during system startup.

I'm starting to consider the possibility of a bug in data transfer (such as a clock spike on SPI) or something similar, but this seems unlikely, as I haven’t noticed any corrupted data up to now. It
seems more like a block-management issue within LevelX.

Does anyone have any suggestions on how to investigate further? Are there any known debugging techniques related to LevelX to identify the root cause of the double-sector mapping?

Thank you in advance for your help.

Best Regards,
Pascal Speck



Back to the top