Just in case, for those who may be in search of this issue and come across
this thread, this was fixed in:
https://github.com/apache/incubator-nuttx/pull/4872 (stm32f7:sdmmc defer
invalidate until after DMA completion)
сб, 19 сент. 2020 г. в 13:28, Bob Feretich <bob.feret...@rafresearch.com>:
> 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> 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>:
>>
>>> 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).
>>> [image: изображение.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.
>>>
>>
>
