SD card corruption when run in release mode

[v8dave]

Hi All,

I have an issue with the SD card in that when running in debug it works fine with no errors. This is the output from debug of the files on the SD card

FAT mount to SD/MMC successful
SD/MMC drive change successful
Files on disk:
------------------------------------------
File [DATALOG.TXT] : 1673 Bytes
File [AX9000BM.CFG] : 1800 Bytes
File [CANBUS.CFG] : 176 Bytes
File [MODBUS.CFG] : 480 Bytes
------------------------------------------
Sensor Config read OK
CAN config read OK
Modbus config read OK

The configuration files are when loaded correctly as show above. It can run for hours saving data to the log file (DATALOG.TXT) with no errors.

If I now compile and run in release mode I get this on the debug output

FAT mount to SD/MMC failed: F_ERR_NOTFORMATTED
Files on disk:
------------------------------------------
------------------------------------------
No config, loading defaults
No CAN config, setting defaults
No Modbus config, setting defaults
*** Error in f_getfreepace(): Free RAM = 4734976


I am using a modified mmc_mcf file because I am sharing the SPI with a touch screen driver. I have code to enter and exit critical when raising and lowering the CHIP select
OSCritEnter(&ShareQSPI, 0);
and
OSCritLeave(&ShareQSPI);

Each time the baud rate is reprogrammed. This was all done with Netburners asistance when I started this design.

If I switch back to DEBUG it reads the SD perfectly again.

Anyone any ideas where I should start to look into this?
Cheers
Dave...

[tod]

V8,
I see this and my brain jumps to "timing problem". The first thing I would do is change some things in Release one at a time (documenting them as I go) to make Release more like Debug, until the problem goes away. I don't know how your environment is configured but the first thing I would check is the compiler optimization level. In the past I have found optimization bugs so it might not be timing it might be an actual bug in the compiler but that tends to be unlikely. A working optimization could just be causing a timing issue that causes your code to fail.

Tod

[Ridgeglider]

It looks like the f_mountfat() call may be failing. The error message you mention is produced by the InitExtFlash() function in the file FileSystemUtils.cpp. Line 173 in the version I have open...

[rnixon]

Timing problem definitely jumps to my mind as well, but also optimization, which could result in a timing problem, a memory problem, or a variable used to check the status of something external that works with optimization off, but is optimized to a register when optimization is on.

[Ridgeglider]

Maybe a variable that should be declared as volatile that gets checked as desired in debug, but not when optimzed for release?

[v8dave]

Hi all,

Thanks for the ideas. The optimisation in release mode was set to most (-O2) so I have set this back to NONE as a start.

The question I have is how to set optimisation for the system files. If I set the option in the project and then choose rebuild all, does it apply this or do I need to make changes a MAKE file somewhere?

Thanks
Dave...

[rnixon]

I would not change any optimization from the standard release. This just covers up the problem, like a missing volatile. The main problem with this method is that it will get forgotten the next time you update tools, or changes with a new compiler release, and then you have problems again. Others may disagree with me.

One thing you can do with the optimization setting is narrow it down to a specific file if you don't know where the problem is, such as turning it off one file at a time until the problem goes away. Then look at your code and see if there are some likely areas for the problem. I don't think there is any indication at this point that its a system file problem.

The other issue with debug/release is that the fast buffer stuff is not used in debug builds, so that could be a timing issue as well.

[v8dave]

Hi

I tried to set optimisation only for the project and same result.

I then found the MAKE files for the system files and as a test I set this to NONE and still the same result. The optimisation has been reset to the default.

The issue is that I can't debug into fatmount so I am unable to determine what the issue is.

If the fast buffer is the issue here I can live without this in this application as I am not writing to the disk on a regular basis and the logging task is on it's own anyway and won't affect the rest of the system. I just need to see how to disable this and get it working.

Dave...

[v8dave]

I have gone through a load of checks. I have 2 applications using the same drivers. Both give the same failure on the SD file card in release mode.

All other parts of the design are working in either release of debug, the graphics display, the touch driver (using SPI), the real time clock etc etc.

I noticed in the linker settings that there is only a single FatFile.a library and no debug version. With this in mind, the fault has to be outside this library as both would be using this one library. I am wondering if this is something to do with the MOD5234 libraries.

Dave...

[rnixon]

I read your first post again. Is there any possibility that there is a h/w complication and one of the two devices you are sharing is not letting go of the bus fast enough? What if you added OSTimeDly() before and after each switch just as a check? Does it make any difference if you disconnect all h/w except the sd card? Having a modified shared spi driver could be responsible.