By the way, the signature of this problem is corruption of either the
first or last 16 bytes of a 512-byte sector.
The M7 cache line size is 32 bytes. The standard Nuttx malloc uses a
16-byte alignment. Losing 16-bytes of a FAT table or directory will
cause all sorts of strange things to occur.
Regards,
Bob
On 9/18/2020 8:54 AM, Bob Feretich wrote:
Just a thought....
On M7 devices, the DMA buffers need to be cache line aligned. Nuttx
has special malloc functions configurable for FAT buffers.
Also, I'm not sure the cache invalidate code was tested well for
store-into cache mode. Store-through was known to be working.
-Bob
On Fri, Sep 18, 2020, 3:11 AM Oleg Evseev <ev.m...@gmail.com
<mailto:ev.m...@gmail.com>> wrote:
I've debugged this issue and found out that in such moments
fs_buffer is not filled fully - if I read the same cluster from pc
- fat chain is ok.
Moreover I found that after a few steps in debug fs_buffer gets
fully filled as it is on an sd card. So it looks like the issue is
related to hardware read using dma (CONFIG_STM32F7_DMACAPABLE=y,
CONFIG_STM32F7_SDMMC_DMA=y).
MCU is stm32f767
It doesn't happen every time, but quite rare. Any thoughts where
should I look further?
пн, 7 сент. 2020 г. в 10:49, Oleg Evseev <ev.m...@gmail.com
<mailto:ev.m...@gmail.com>>:
Hi all,
I'm working with stm32f7 custom board and px4 firmware, but my
concerns are with the NuttX FAT32 driver. I have an issue. PX4
logger module writes high rate data to SD card successfully
awhile, until at some point write func return error 28 (“No
space left on device”) while there is a lot of free space on a
card (29GB out of 30GB).
I had this error several times on two different SD-cards. I
don't do a lot of tests, but it seems that SanDisk Extreme Pro
is less prone - it can write 100+ Mbytes files without errors,
while SanDisk Extreme usually breaks a little earlier.
The board is on the table, no vibrations (at least any
significant).
I dig a little and can see that 'fat_write' try to extend the
current cluster by one calling 'fat_extendchain' func that on
existing chain extending verifies that this is a valid cluster
by examining its start sector, but 'startsector =
fat_getcluster(fs, cluster);' returns 0:
else if (startsector < 2)
{
/* Oops.. this cluster does not exist. */
return 0;
}
In 'fs_buffer' there is indeed 0 for this fatindex (see picture).
изображение.png
I didn't dig much in the driver and fat32 itself. What should
I check, where it is useful to set breakpoints, etc.?
Can any hardware issues be the reason for such error
theoretically?
Can any previous power shutdown and unfinished writings (in
fact shutdowns can be on every launch and I already have
several corrupted files), breaks FAT system itself in that way
it can lead to this exact error for new sessions?
Thanks in advance for any help!
---
With regards, Oleg.
