littlefs icon indicating copy to clipboard operation
littlefs copied to clipboard

littlefs/lfs.c:1228:error: Corrupted dir pair at {0x0, 0x1} littlefs/lfs.c:1886:debug: Bad block at 0x0 littlefs/lfs.c:1891:warn: Superblock 0x0 has become unwritable.

Open SaiPraveen22 opened this issue 2 years ago • 3 comments

Hello, I am STM32L5 microcontroller, 16MBytes Flash in QuadSPI mode and im using lfs im getting the error, but i think its due to incorrect device configuration or not enough frequency to run the memory can anyone tell me correct configuration for my memory and my memory type is Winbond W25Q128FV(waveshare W25Q DataFlash Board) im posting my configuration below. // block device configuration .read_size = 64, .prog_size = 64, .block_size = 4096, .block_count = 4096, .cache_size = 16, .lookahead_size = 512, .block_cycles = 500, can any one tell how to make this configuration and what is the minimum frequency to work the memory?

even the memory is disconnected, i am getting the error given below littlefs/lfs.c:1228:error: Corrupted dir pair at {0x0, 0x1} littlefs/lfs.c:1886:debug: Bad block at 0x0 littlefs/lfs.c:1891:warn: Superblock 0x0 has become unwritable. Does anyone faced the issue, please help me resolving it.

SaiPraveen22 avatar Jun 08 '22 14:06 SaiPraveen22

我也是这个问题,我追踪到是在lfs_dir_commitcrc for (lfs_off_t i = off; i < noff+sizeof(uint32_t); i++) { // check against written crc, may catch blocks that // become readonly and match our commit size exactly if (i == off1 && crc != crc1) { DEBUGMSG("%d %d %d %d\r\n",i,off1,crc,crc1);//1051 1051 1112129508 -1185462968 return LFS_ERR_CORRUPT; } 这个if这里报的错,现在不知道如何处理

kuangpan avatar Jun 29 '22 10:06 kuangpan

have you resolved this issue? i have same issue like you

KpuFish avatar Jul 31 '22 10:07 KpuFish

I also have similar issue and have tracked it down to wrap-around of block allocator. My blocks are 64x4096 (erase block size) with write blocks (pages) 4096 bytes. I also use a lookahead_size of 512 assuming it can store entire flash area of 4096 blocks. My superblocks are located in block 0 and 1. What I found is that depending on seed, it will start allocating at a random position in flash and while writing a large file it will overwrite the superblocks when allocation free.off + free.i wraps. I do not know why this is. Does it not understand that storage area and superblocks share common flash?

kyrreaa avatar Oct 18 '23 10:10 kyrreaa