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 > > >
