SD card corruption when run in release mode

[v8dave]

Hi rnixon,

Good thought but none of the other tasks are even started or created at this point. The SD is enabled and attempted to be mounted prior to all the tasks being created and setup.

I thought about your idea of the other devices not being initialised correctly but all the IO is initialised at startup prior to the SD init. I set all the CHIP SELECT outputs to HIGH so that they are not enabled. No difference. Still same error.

I only have 2 SPI devices on this design. The SD card (Micro SD) and a touch screen controller (ADS7846). SD is on J2[35] and TS is on J2[40]

I can confirm that J2[40] does not go low during the SD init.

A redesign of the PCB may have to be done and I will move the touch screen controller to use the eTPU SPI instead as I have the spare capacity to do this. I am considering this as an option if I cannot sort out this issue. I would prefer a software solution but I may have no choice if I can't get it to work.

I may hook up the logic analyser today and take some recordings of the debug and release versions and see if there is a difference.

Dave...

[rnixon]

Ok, yet another idea. How about if you write an app on your custom board that does nothing but run the sd card and display in a single usermain task? Things this might rule out:
- A conflicting interrupt or some kind of interrupt interaction
- I'm not sure about want needs to be done, but I remember reading something about having to add code for each task that would access the file system. You would still need to do that for the single usermain task
- Some odd blocking task behavior in your full code set that causes a timing interaction

If that all worked you could make the test more complicated by adding a task and running each spi device separately

[v8dave]

Hi rnixon,

I was considering this very same option. I may do this today.

I have modified mmc_mcf.cpp as per instructions from Netburner with regards to using an OSCritEnter and Leave in the chip selects. This and the code to re-enable the SPI each time it is called in chip select low. This is the code below. (I have cut out all the #defines for showing here but they are still in the actual code I use)

Code: Select all

void spi_cs_lo( void )
{
  // J2[35] = 0;
   OSCritEnter(&ShareQSPI, 0);
   QSPIInit( /*Baud*/ 100000, /*QueueBitSize*/8, /*CS*/ 0xF, /*CSPol*/ 0x1,
                      /*ClkPolarity*/0x0, /*ClkPhase*/ 0x0, /*DoutHiz*/ TRUE);
   spi_set_baudrate(spi_baud_rate);	// Set the last rate we used

   sim.gpio.pclrr_etpu = ~0x01;
}

spi_baud_rate is initialised at 100000 where it is defined.

And this is the chip select hi.

Code: Select all

void spi_cs_hi( void )
{
   sim.gpio.ppdsdr_etpu = 0x01;

   spi_baud_rate = spi_get_baudrate();   // Save the baud rate we were last using

   OSCritLeave(&ShareQSPI);
}

The ShareQSPI is setup at the start of the main code, before any SD filing calls are made. Below is the spi init in mmc_mcf.cpp

Code: Select all

int spi_init (void)
{
  OSCritEnter(&ShareQSPI, 0);		// Need this here as the spi_cs_hi call will call leave

  iprintf("Enabled SPI for SD Card\r\n");

  MMC_BaseInit();
  spi_cs_hi();

  return(0);
}

[v8dave]

Ah ha!!

I just tried something out. I uncommented all the OSCritEnter and leave and the initialisation of the SPI and put in a permanent loop after the init code and it works. The SD gets initialised.

I then put back in the OSCritEnter and OSCritLeave calls and it still works.

I then put back in this code and it fails.

Code: Select all

  
   QSPIInit( /*Baud*/ 100000, /*QueueBitSize*/8, /*CS*/ 0xF, /*CSPol*/ 0x1,
                      /*ClkPolarity*/0x0, /*ClkPhase*/ 0x0, /*DoutHiz*/ TRUE);
   spi_set_baudrate(spi_baud_rate);	// Set the last rate we used

I put in some code to check the baud rate value I was setting and it returns this.

Baud rate = 9249700

Running in debug I get the same value but there the code works.

[v8dave]

Further testing and I finally have something working.

If I comment out the QSPIInit it still fails with the call to spi_set_baudrate being called.

I can live without the QPSIInit because both the touch screen driver and the SD card use the exact same settings but I do need the baud rate to be changed as the touch screen driver won't work at the higher rate. I have tried and it wont' work.

With further testing I get the following debug output that I added to spi_set_baudrate in mmc_mcf. It shows the baud rate changes for the SPI.

Enabled SPI for SD Card
BR changed (100000)
BR changed (25000000)
FAT mount to SD/MMC successful
SD/MMC drive change successful

This next line appears after the SPI is enabled for the touch screen driver.

BR changed (18499400)

The values don't seem the match but this could just be rounding errors with the setting code and reading it back.

By putting the code to reset the SPI to the last known baudrate in the touch screen driver when it raises the chip select and before it calls OSCritLeave, instead of the init of the SD card chip select, it now all works and data is recorded to the disk and I it runs at the higher speed now.

Touch screen works fine.

Off to try the code on the other project to confirm that works. It does a lot more SD access so will be a good test.

[EDIT] It works perfectly. Now leaving it running and logging data every 5 seconds to see how it behaves.

Dave...

[tod]

I didn't actually follow all the details but it sounds like you are saying the baud rate gets set to a value you don't expect so you reset it to a value you do expect and things work. If that's true are you just masking the problem and not fixing it. Instinct says you overwrote something in memory and you are just writing it back to what it should be. Obviously, I can't be sure this is the case but if it is, you are almost guaranteed to get bit by this at some point in the future. Probably after you've forgotten almost all the details of this project. Usually, I suspect printf and sprintf calls but typically that would make things fail in debug and not in release (because many people don't produce their debug messages in release mode) but you have the opposite problem. However, if you have conditional code that varies from debug to release it could easily change what's getting overwritten in memory and show as a crash in release and work in debug. This is one of those things that makes linting your code worth the effort.

[nirias999]

If I understand this correctly, you are seeing the mysterious baud rate change in both the debug and release builds, since your debug prints are showing the error. You thus still can not know why the release build was behaving differently. Simply moving the baud rate set code to a different location is probably just changing the timing and/or memory utilization enough to temporarily mask the problem in the release build.

I would agree with Tod's suggestion that you presume this problem will return at some point in the future. It would be wise to spend the time to find the root cause of the underlying problem now while the code is all fresh in your mind.

[rnixon]

I may not know what I'm talking about here, but isn't there some type of autobaud that takes place with SD cards? I think you ask for a rate, but that is just the maximum.

[v8dave]

This is one of those things that makes linting your code worth the effort.

Thanks guys. As I said, I have it working but I am not happy with the solution as there is no reason why the code should not work as it was originally.

I am going to play around with it this coming week to get to the bottom of it. It happens in 2 different applications that have different code ourside of the common stuff. I will also make a completely strip down version with no graphics or other code etc and see how this reacts.

Tod, quick quesiton on Lint? Where can I get this and can it be integrated into Eclipse? I have no experience of it in the past (poor when you consider I write nearly all code in C/C++ but have had no issues with my code bases before)

Cheers all
Dave...

[tod]

I wrote up a blog post about a year ago on using Lint with Eclipse and the NetBurner. It has all the links you'll need. A word of warning though. If you are in the midst of trying to meet a deadline you don't want to start messing around with lint. Unfortunately, it takes some work to get lint set up and working the way you want. It's best to get familiar with lint when you aren't under pressure. Ideally once you have it set up then you use it from day one of a new project and the list of warnings and suggestions is much more manageable. On an existing project you're likely to get hundreds of hits. It can still be invaluable, it just takes patience to weed through all the warnings to find the ones that can be related to your current problem. It will tell you about potential memory leaks and boundary problems so you can focus on just those.