Corrupted Data on the SD card from STWINK HS Data Logger

[LWeir.775]

Reducing the number of sensors enabled in the configuration file helps, as does slowing down the SD clock (i.e. increasing hsd1.Init.ClockDiv = n in STWIN_sd.c). We've also noted that the code in sd_diskio.c has the compile time build define "ENABLE_SCRATCH_BUFFER". Please can you say if this should or should not be switched on for the StWin1b hs data logger ?

[Tesla DeLorean]

Sorry, not familiar with this project.

The scratch buffer method I originally developed for the F4 SPL addressed the unaligned memory issue when using DMA, which needs 32-bit alignment.

It would decompose read/writes into single sector accesses via an aligned buffer, either on the stack or statically allocated.

If you do f_read/f_write with large requests that are sector multiples, sector aligned, and with 32-bit aligned source/dest memory the scratch buffer won't be needed.

Where things get ugly is if you do a lot of small or spanning writes which require FatFs to shuffle and deblock, using portions of your original buffer at a byte level.

SDIO is going to be woefully inefficient with non-sector aligned file IO, you should buffer 8KB or up to 32KB and manage/wrap your output functionality to optimize writing in multiple sectors, on sector or cluster boundaries within the file.

If you're using DMA, and randomly sized f_read/f_write, you're going to want to "double buffer" rather than "transfer in place"

You could add an assert() to the routines in DISKIO layer to confirm this as a potential failure mechanism.

ST's implementation for POLLED transfers is also VERY WEAK, rather than optimize the normative case, it cripples all transfers to handle the potentially unaligned ones.