FatFs f_mkdir() fails always when not in Debug mode

[Lars Beiderbecke]

I'm using FatFs on an STM32F722 with Cube V1.12. FatFs works well: I can mount, open, read, write, rename, stat, and unlink data.

But f_mkdir() fails every single time, unless I'm running in debug mode. It's exactly the same code with f_mkdir(). The error code returned is FR_DISK_ERR (1).

Alas, I cannot debug this further, because I'm then not seeing this bug.

Has anybody ever seen something like this, or can offer an explanation why debugging vs. running should have an impact on f_mkdir()? The only difference that comes to my mind is interrupts, but looking at the f_mkdir() code I'm not seeing how that should happen.

[Lars Beiderbecke]

I should have given an example of the failing f_mkdir code:

int rc = f_mkdir("test/dir1")

where test/ is an existing directory.

[AvaTar]

You could add telemetry code, to check why it fails.

But first I would check for differences between your debug and release project. Optimizations, added/removed code, timing issues ?

[Lars Beiderbecke]

Sorry, that is not why I meant. It's the same Debug project, but in one case I'm using "Run" and in the other case I'm using "Debug" to execute the code. These modes only differ by their startup scripts, where Debug has an extra

monitor reset
tbreak main
continue

[Lars Beiderbecke]

I did some further testing, and need to correct my statement above: Only read operations (f_read, f_stat, ...) work, but all write operations (f_write, f_mkdir, f_rename, ...) work only when I'm debugging and single-stepping.

I tried lowering the clock rate by increasing the SDMMC1 divider, but that doesn't have any effect. And I'm using micro-SD cards, which cannot be "write-protected".

[Tesla DeLorean]

The debugger changes the responsiveness of the system and the dynamics of DMA, IRQ etc, and provides contention and subtle changes in speed.

As I think I've explained on many occasions before, I have the DISKIO layer instrumented to output failure conditions on the READ/WRITE. I do this via a serial port so I can observe issue with and without the debugger, and with production vs debug releases.

The polled loops in the SDMMC code have issues with interrupt and bus loading

[Lars Beiderbecke]

Thanks for the suggestion, I already use a serial port for tracing. I'll try instrumenting the FatFs code, although I'm not sure how to interpret or even fix an error in a certain part of the code.

If some part of the FatFs/SDMMC code cannot be used while interrupts are on and triggering, what is the correct way to handle this? Isn't this a common case? My interrupts are crucial and cannot be turned off.

Also note that reads are fine, even when not single stepping. Wouldn't they use loops as well? Besides, I'm not using DMA here, so what kind of time-critical loops would that be?