lfs_cache_prog: assert(pcache->block == 0xffffffff)

[guillaumerems]

Hi,

I see sometimes this ASSERT, is there a way to recover when it happens and understand when this could happen ?

Thanks

[guillaumerems]

To add more information, I observe that every time I see this assert, just before it was in "fill with 0" behavior in lfs_file_write

[geky]

Hi @guillaumerems,

That assert means that littlefs tried to reuse a program cache that wasn't written out yet. It is most likely a bug in littlefs.

What file operations led to this failure? You mentioned "fill with zeros", are you referring to this line? Did you seek past the end of the file to fill it with zeros?
https://github.com/geky/littlefs/blob/master/lfs.c#L1562

Some other info that would help: What is your block device's geometry? (read size, program size, erase size) and compiler+arch?

Thanks for reporting

[guillaumerems]

Exactly it is this line, I added a log when fill with zero happen and when it happens, I have the assert right after.

My configuration is the following:

		.read_size = 128,
		.prog_size = 128,
		.block_size = 4096,
		.block_count = 7152,
		.lookahead = 128,

The processor is a Cortex-M4 (STM32L4), the Flash is a NOR Flash (512Mbits)
Compiler GCC with optimization Os

[geky]

A few other questions:

• Did you seek in the file beforehand?
• Did you call lfs_file_truncate?
• What is the hash of littlefs that you are using?

There were two fixes that went in recently related to seek (aea3d3d) and non-powers-of-2 block counts (425aa3c). So it may be worth trying to update to the current master.

[guillaumerems]

No seek, no truncate
It is only a file_open and then write
I am using the last version updated of today.

I will continue the test to see when a fill to zero can happen because it does not happen all the time

[geky]

What flags do you pass to lfs_file_open?

The fill to zero should only happen when you seek past the end of a file and write data. So something must be going wrong inside littlefs.

You're not calling littlefs from multiple threads are you? (or from interrupts)

Another possibility is that the ctz/popc intrinsics aren't being emitted correctly by the compiler, though I would be surprised on gcc, since I've been using gcc for a while without issues. You could try replacing the intrinsics in lfs_util.h with their software equivalents and see if that improves things:

static inline uint32_t lfs_ctz(uint32_t a) {
    uint32_t r = 32;
    a &= -a;
    if (a) r -= 1;
    if (a & 0x0000ffff) r -= 16;
    if (a & 0x00ff00ff) r -= 8;
    if (a & 0x0f0f0f0f) r -= 4;
    if (a & 0x33333333) r -= 2;
    if (a & 0x55555555) r -= 1;
    return r;
}

static inline uint32_t lfs_npw2(uint32_t a) {
    uint32_t r = 0;
    uint32_t s;
    s = (a > 0xffff) << 4; a >>= s; r |= s;
    s = (a > 0xff  ) << 3; a >>= s; r |= s;
    s = (a > 0xf   ) << 2; a >>= s; r |= s;
    s = (a > 0x3   ) << 1; a >>= s; r |= s;
    return r | (a >> 1);
}

static inline uint32_t lfs_popc(uint32_t a) {
    a = a - ((a >> 1) & 0x55555555);
    a = (a & 0x33333333) + ((a >> 2) & 0x33333333);
    return (((a + (a >> 4)) & 0xf0f0f0f) * 0x1010101) >> 24;
}

[guillaumerems]

I open the file in a+ for append.

I am under preemptive FreeRTOS so yes the functions could be called from several thread, but I have a littlefs_hal on top of it with a mutex implementation to prevent several thread calling the function
But it could be possible that there are 2 open in the same time, and other operation between an open and a write
But every lfs functions are protected by a mutex.

I will try the function lfs_ctz / lfs_npw2 / lfs_popc

[geky]

Hi @guillaumerems, do you know if this could have been fixed by #12?

I haven't been able to put together a reproducible case for this yet, so sorry I don't have more info here.