LevelX initialization time problem

[SimonTechv]

I ported levelX to work with the STM32F412ZGT6 discovery board with MICRON N25Q128 SPI flash memory. The volume used is 4096 sectors (physical) of 4 kilobytes each.

Before starting to work with wear-leveled flash memory, I call the function:

_lx_nor_flash_open(&nor_mem_desc, "VOL0:", flash_driver_init);

Its execution takes about 1 second. In the image below, I provide the necessary information:

I looked through the code and found that during the initialization process levelX reads all blocks of flash memory.

Is it possible to reduce the startup time without reducing the memory size? I plan to use 1 Gbit NOR memory, but in this case the initialization time will increase several times more.

For more information, I have uploaded the project code

[rahmanih]

Hi @SimonTechv, Could you try to customize the "lx_user.h" by enabling the 2 following flags:

• https://github.com/eclipse-threadx/levelx/blob/ec683ddf1461a05e462d301bf8a15124136b2ca0/common/inc/lx_user_sample.h#L97
• https://github.com/eclipse-threadx/levelx/blob/ec683ddf1461a05e462d301bf8a15124136b2ca0/common/inc/lx_user_sample.h#L106

after enabling this flags you'll need to call in the API: lx_nor_flash_extended_cache_enable just after the lx_nor_flash_open() .

[SimonTechv]

@rahmanih, I tried to enable all the options you described, but it did not affect the initialization speed.

Sometimes an INVALID_BLOCK error occurs during operation, which never disappears. Is this normal behavior or does it require careful investigation?

UPD: I found critical error in QSPI NOR DRIVER in Page programm algorithm. I will fix it and retest module soon.

[rahmanih]

@rahmanih, I tried to enable all the options you described, but it did not affect the initialization speed.

Sometimes an INVALID_BLOCK error occurs during operation, which never disappears. Is this normal behavior or does it require careful investigation?

UPD: I found critical error in QSPI NOR DRIVER in Page programm algorithm. I will fix it and retest module soon.

could you try to test with 64K block size?

regards haithem.

[SimonTechv]

@rahmanih, I tried to enable all the options you described, but it did not affect the initialization speed. Sometimes an INVALID_BLOCK error occurs during operation, which never disappears. Is this normal behavior or does it require careful investigation? UPD: I found critical error in QSPI NOR DRIVER in Page programm algorithm. I will fix it and retest module soon.

could you try to test with 64K block size?

regards haithem.

I changed the sector size to 64 KB. Initialization time has been reduced to 700 milliseconds. However, when I did fault tolerance testing, I found out that a sudden reset damages the internal data structure. In my case, after 10 random resets while recording, I get an error. The error appears here.

[rahmanih]

@SimonTechv

I changed the sector size to 64 KB. Initialization time has been reduced to 700 milliseconds. However, when I did fault tolerance testing, I found out that a sudden reset damages the internal data structure. In my case, after 10 random resets while recording, I get an error. The error appears here.

after switching to 64KB, you'll need to erase the NOR flash and reformat it, did you do that?

[SimonTechv]

@rahmanih Yes, I have completed these operations. I can provide a memory dump for a thorough analysis of the fault and tell which specific block the error occurred in, if necessary.

[rahmanih]

I found out that a sudden reset damages the internal data structure For more information, I have uploaded the project code

Sorry but there isn't any 'fault tolerance' code within your project.

[SimonTechv]

@rahmanih Protection against power failures is littered in the LevelX documentation. I'm using a random external reset generator for the microcontroller, so my code just uses sequential writing.

UPD: I suppose I need to run tests on the peripherals and the driver to exclude their influence on the error. Because I see that there is regression testing in the project repository and I believe it passes successfully.

[rahmanih]

@rahmanih Protection against power failures is littered in the LevelX documentation. I'm using a random external reset generator for the microcontroller, so my code just uses sequential writing.

unless I'm missing something, but I think the fault tolerance is managed at FileX. https://github.com/eclipse-threadx/rtos-docs/blob/main/rtos-docs/filex/chapter6.md

[SimonTechv]

@rahmanih Official Docs page. LevelX can exist separately from FileX.

[SimonTechv]

I noticed this line. There are many more 512 byte blocks in a 64 kilobyte block than described in the comment I want know about limitations for main settings.

UPD: I perform testing my driver functions. I didn't find any problems. However, a sudden reboot breaks the LevelX internal block structure. I'll try to return to 4K sectors and test again.

[rahmanih]

I noticed this line. There are many more 512 byte blocks in a 64 kilobyte block than described in the comment I want know about limitations for main settings.

UPD: I perform testing my driver functions. I didn't find any problems. However, a sudden reboot breaks the LevelX internal block structure. I'll try to return to 4K sectors and test again.

Hi @SimonTechv, again I don't think levelx would be able to handle 'power loss' issues alone, it needs to journalize any on going operation. Tody this is not done but offered by FileX fault tolerance module. I could be wrong, so may be @xiuwencai can confirm that.

regards Haithem.

[rahmanih]

closing this issue as solution is provided.