Hi Reto, Just a curiosity: why are you using SDCard support over SPI? Isn't your board prepared to use native SDCard/SDIO peripheral?
BR, Alan On 5/19/21, Reto Gähwiler <gret.hexa...@gmail.com> wrote: > Hey again, > > About the requested configuration of the SD-Card, here we go: > CONFIG_MMCSD=y > CONFIG_MMCSD_SPI=y > CONFIG_MMCSD_SPICLOCK=25000000 > > About the multiblock, I don't think we are using that. Let me know how I > could recognise it if not in the config. > > Thanks, Reto > > On 2021/05/19 12:13:35, David Sidrane <david.sidr...@nscdg.com> wrote: >> Hi Reto, >> >> What is the clock rate to the card and is multiblock enabled? >> >> David >> >> -----Original Message----- >> From: Reto Gähwiler [mailto:gret.hexa...@gmail.com] >> Sent: Wednesday, May 19, 2021 5:08 AM >> To: dev@nuttx.apache.org >> Subject: Re: RE: Nuttx FAT32 issues - corrupted files, wrongly stated >> free >> clusters by statfs >> >> Hi David, >> >> It is running on an STM32h743zi version V or Y. The SD-card in use is a >> SwissBit S-45u. >> >> Reto >> >> On 2021/05/19 11:11:22, David Sidrane <david.sidr...@nscdg.com> wrote: >> > hi Reto, >> > >> > What SoC is this on? What type of card are you using? >> > >> > David >> > >> > -----Original Message----- >> > From: Reto Gähwiler [mailto:gret.hexa...@gmail.com] >> > Sent: Wednesday, May 19, 2021 3:22 AM >> > To: dev@nuttx.apache.org >> > Subject: Re: Nuttx FAT32 issues - corrupted files, wrongly stated free >> > clusters by statfs >> > >> > Hello Jukka, >> > >> > Thanks for your quick reaction. I applied your PR to our "outdated" >> > nuttx. >> > Unfortunately, it did not show any impact on the statfs behaviour if >> > the >> > card is corrupted. Though, meanwhile I do have hands on two images. >> > >> > #1 the mentioned one. Although, the files/dirs are all deleted. But >> > still >> > same behvaiour and a chkdsk error. statfs reports 703 MB free while the >> > sd-card was deleted! >> > >> > #2 Having the file structure in place and contains plenty of logfiles. >> > Many >> > of them with the mentioned corruptions. The card is filled to 100%. But >> > here >> > the behaviour is slightly different. Checking the FSINFO block and then >> > removing some files under Windows doesn't impact the FSINFO section. >> > But >> > once inserted to the device statfs reports the correct size and updates >> > the >> > FSINFO section. However, the card also shows corruptions if chkdsk is >> > applied to it. >> > This behaviour is identical before and after applying your PR. >> > >> > Brgds, Reto >> > >> > On 2021/05/18 19:55:06, Jukka Laitinen <jukka.laiti...@iki.fi> wrote: >> > > Hi, >> > > >> > > There seems to be a bug in sector calculation which may trigger with >> > > e.g. corrupted fs. I just made a PR for this, >> > > >> > > https://github.com/apache/incubator-nuttx/pull/3740 >> > > >> > > But I really don't know if this is related to your issues, this is >> > > just >> > > something that suddenly popped up elsewhere. >> > > >> > > -Jukka >> > > >> > > >> > > On 18.5.2021 16.10, Reto Gähwiler wrote: >> > > > Dear All, >> > > > >> > > > First of all, in case a similar thread pops-up authored by myself, >> > > > please >> > > > ignore. >> > > > >> > > > Recently we discovered some issues with the FAT32 partition on the >> > > > SD-Card >> > > > used in our device running on nuttx. There are actually a bunch of >> > > > issues >> > > > we are strugle to understand related to the filesystem. >> > > > The issue discovered recently is, that a statfs call won't return >> > > > the >> > > > true >> > > > number of free clusters. It rather returns what ever is in the FS >> > > > INFO >> > > > section of the FAT32 partition. Inserting such a "corrupted" card >> > > > into >> > > > an >> > > > SD-Card reader and mounting it to Windows shows following: >> > > > >> > > > #1 Windows file explorer reports the correct free space. >> > > > #2 Comparing the free space in file explorer and looging at FS INFO >> > > > section >> > > > with "Active - Disk Editor" doesn't line up. Windows wouldn't write >> > > > any >> > > > longer the FS INFO section on that card. Even if all the >> > > > files/dires >> > > > are >> > > > wiped from the card. >> > > > #3 Whenever files are added / removed under nuttx the FS INFO >> > > > section >> > > > would >> > > > be updated by nuttx, but to the wrong number since the base is >> > > > wrong. >> > > > #4 Mounting the card to linux and properly unmount it might >> > > > actually >> > > > fix >> > > > the issue. But not always! >> > > > #5 Quick format the card resolved the issue too. Windows would once >> > > > again >> > > > write the FS INFO section and nuttx would shows the correct free >> > > > space. >> > > > #5 Running a "chkdsk /f" under windows on that broken SD-Card fixes >> > > > the >> > > > issue too. Reporting a broken file in a root folder on that card. >> > > > >> > > > We indeed had issues with corrupted files in the past. Usually in >> > > > the >> > > > logging directory, which is accessed most. How they corrupt we do >> > > > not >> > > > know. >> > > > The corruption is recognised in the following ways: >> > > > >> > > > #A cryptic and too long file names, we only make use of short file >> > > > names >> > > > (8.3) >> > > > #B files whcih became folders >> > > > #C sizes which are not possible >> > > > #D combinations of the above >> > > > >> > > > Our application supervises the SD-Card with statfs and removes >> > > > files >> > > > once >> > > > we hit a quota of 0.85. Therefore, the card is not filling up. >> > > > However, >> > > > the >> > > > most recent recognition of this behvaiour was due to an application >> > > > bug >> > > > which allowed the card to fill up under some circumstances. >> > > > Playing around with a quickformated SD-Card, filled up with data >> > > > and >> > > > trying >> > > > to retrigger the issue revealed that I never get the ENOSPC but >> > > > only >> > > > EIO >> > > > once the card is full! But never managed to get the statfs issue. >> > > > For the logging we use the fstream family (fopen, fwrite, fread, >> > > > fflush, >> > > > fsync) commands. For config files and other things also the low >> > > > level >> > > > read/write are used. >> > > > >> > > > One more thing, among all the logging files we once in a while have >> > > > corrupted file content. Typically that is a skipped byte or doubled >> > > > byte >> > > > (we use protobuf and can see that encoding the binary). This seems >> > > > to >> > > > happen during reading but also writing the file. >> > > > >> > > > At the moment we didn't investigate the fat driver of nuttx but >> > > > rather >> > > > tried to analyse the problem. And now we have a bunch of question >> > > > marks. >> > > > >> > > > #1 Has anyone recongised similar issues? >> > > > #2 Does anyone know a tool which can be used in nuttx equivalent to >> > > > chkdsk >> > > > under windows? Or do quick format? >> > > > #3 Why is there no ENOSPC but EIO once the card is full? >> > > > #4 What triggers the corrupted files? How robust is the nuttx FAT32 >> > > > considering stackdumps and powerlosses? >> > > > >> > > > For the purpose of investigation, I have an image of the SD-Card >> > > > when >> > > > it >> > > > was in the state of reporting wrong sizes in nuttx. >> > > > >> > > > Looking forward to your answers and ideas. Appreciate your help, >> > > > >> > > > Reto >> > > > >> > > >> > >> >
