You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Fabien Lepoutre <fa...@culvertengineering.com> on 2019/09/12 01:54:45 UTC

Re: FAT32 file system issue

FIgured it out.
Issue #1995.

On Mon, Aug 26, 2019 at 10:05 AM Fabien Lepoutre <
fabien@culvertengineering.com> wrote:

> Thanks for your fast answer Fabio,
> No the file sized are indeed in GB. Yes it is a lot of data :)
> I had a look at the history but looks like it hasn't been changed since
> 2015. Most of the focus has been on exFat since.
> I could try out the exFat format to see if it's better.
> I did my own version of the mmc driver so maybe that is the issue. I will
> take a look at it. But as the addresses are calculated in the fatFS I would
> have thought the issue would come from higher layer.
> I'll keep you posted!
> Fabien
>
> On Mon, Aug 26, 2019 at 9:58 AM Fabio Utzig <ut...@apache.org> wrote:
>
>>
>> On Mon, Aug 26, 2019, at 1:39 PM, Fabien Lepoutre wrote:
>> > Hi all,
>> > I am running code with the FATFS driver to write a stream into an SD
>> card.
>> > The SD card is FAT32 formatted.
>> > Everything goes well for some time but for some reason, after a while
>> (I've
>> > seen the issue come in at file size = 1.5GB, 2GB, 3GB etc...),  the file
>>
>> Do you really mean GB here, or was it a typo? I never tried using big
>> files like this, but don't mind trying myself!
>>
>> > memory location changes (looks like it wraps to the beginning of the SD
>> > card memory) and overwrites the boot block and FAT structure which
>> corrupts
>> > the entire SD card.
>> > I haven't found any similar issues but not sure anybody has tested the
>> file
>> > system to that extent.
>> > Anyone has an idea on where to start to debug that issue?
>> > I'm guessing this bug would be from the fatfs driver and not the
>> mmc/sdcard
>> > driver... am I wrong to think this?
>>
>> Possibly correct, the elm-chan FAT driver used is quite old now, and the
>> maintainer has very good release notes describing fixes, etc; maybe
>> something there can give a hint. Also those sizes are close to the limits
>> that int32/uint32 can store, so it could be overflow, maybe even in the MMC
>> driver...
>>
>> > Thanks,
>> > Fabien
>> >
>>
>