TMS320C5515: CSL v3.04 MMC_write() Returns Spurious CSL_EMMCSD_WRITE_ERROR

Hi Lali,

Answers to questions below in red:

- Was this issue seen with a new batch of boards where this problem was not noticed on an older rev?  The problem was reported on a fairly recent batch of PCB's, but I have been able to reproduce the error on my development PCB which is much older than the boards we originally saw the problem on.

- Has anything changed in your HW? No

- Are you able to put a logic analyzer on the MMC bus and see the transactions when this error occurs? This would perhaps provide some clues on the problem? I can use our oscilloscope, but I'm not sure if the signals are readily available on our PCB, but I will check.

Thanks,

Ben

Ben,

I'm looking into this and will post back more feedback.

Following up on your previous reply. How did you reproduce it on your development PCB?
Trying to understand why this was not observed before. Was there some SW "knob" you had to tweak on your development PCB to start seeing this error?

Lali

Hi Lali,

In regards to why we didn't see the issue in the past, unfortunately the issue is not 100% reproducible and is spurious at best.

Below is a more comprehensive timeline of events.

Recently a customer reported issues with the file system in the unit when they tried to save data.

We have 2 file medias in the unit, on board flash and the micro SD card.

We told them to use the on board flash on our unit instead of the SD card file system, and the file issue went away.

This caused us to evaluate the SD cards closer.

We used a Windows utility which checked the integrity of the micro SD card by writing to the whole card.

This utility also posted the write and read speed that Windows saw when interacting with the micro SD card, and we found that the micro SD cards that gave us trouble had a write speed of roughly 4-5MB/s or below.

We went with that criteria for the time being (write speed) to reject micro SD cards, but then saw an issue with the file system on a 16GB micro SD card from PNY that had a reported write speed of 9MB/s.

This caused alarm since it threw our write speed criteria right out the window, if this micro SD card failed then many more may be subject to the failure.

I then started taking micro SD cards that failed our write speed test to see if I could debug the problem down to its source.

I found that the unit would potentially fail when interacting with the SD card in any of the 3 scenarios:

1.  At startup our unit checks to see if a micro SD card is present.  If a micro SD is present it attempts to initialize it with the default folders.

2.  When the user creates a file.

3.  When the user saves data to a file.

These steps are in order of time, so some SD cards could pass step 1, and then fail on step 2 or 3.

Since catching the failure at step 1 was the soonest in time that is where I have spent my debugging time with the code.

It is during this area that I was able to catch the SD card driver in CLS v3.04 returning the error code.

Thanks,

Ben

One other item to mention.
The default media the unit will use is the on board flash.
The user has to explicitly switch the media choice if they wish to use the micro SD card.
That being said, there may be units out in the field that have this issue but it is unknown to the user since they are using the on board flash and not the micro SD card.

Ben

Hi Lali,
We have the TI eZdsp v2 USB Stick Rev D.
If I can get the issue to occur on this PCB will that work on your end?
I will also post my findings for the different transfer sizes (below 512), and 1GB SD card once tested.
Ben

Edit:

(Added Rev D to the eZdsp model)

Hi Lali,

I have done testing without the file system and the error still happens.

The example code I will provide is pretty short and to the point in regards to getting the bug to show.

It is just a for loop writing to and reading from the micro SD card.

Ben

Hi Lali,

Thanks for the update.

If you have any questions about the project please let me know.

Thanks,

Ben

Hi Lali,

We have tested on the following micro SD cards:

- 2GB SanDisk

- 4GB SanDisk

- 16GB PNY

The supplied code in do_write_test_method() seems to have worked around the issue with the ILLEGAL_COMMAND.

We have yet to see retryCnt exceed 2.  It seems that after a single delay and 1 retry, the micro SD card write always succeeds.

The code path that tries to write less than 512 bytes still fails in the same spot, but we are always writing 512 bytes so this doesn't concern us.

We will continue testing and let you know what we find.

Thank you for the quick response.

Ben

Hi Lali,

Have you tried the below parameters for the test method on the micro SD card that failed to see if it still failed?

do_write_test_method(false, 512);

If the bug was something to do with the micro SD card not being ready for a write right after a read, this code path should hopefully reveal that, but we have not seen this.

Prior to your changes in the test code, a micro SD card that failed with the below parameters:

do_write_test_method(true, 512);

Would pass with the below parameters:

do_write_test_method(false, 512);

Ben

Hi Ben,

Please try the below code snippet for the FALSE section. I think what you had previously was incorrect.

/*
* This code path to date has had no issue with the reads or writes when number_of_bytes_to_transfer
*  is equal to 512.  If number_of_bytes_to_transfer is 256, the write method will get stuck.  No other values other
*  than 512 and 265 have been tested yet.  This code path does not change the timeout registers of the mmc peripheral.
*/

if(MMC_write(mmcsdHandle, (number_of_writes), number_of_bytes_to_transfer, write_buffer_test) != CSL_SOK)
{
if(MMC_write(mmcsdHandle, (number_of_writes), number_of_bytes_to_transfer, write_buffer_test) != CSL_SOK)
              while(1);
}

if(MMC_read(mmcsdHandle, (number_of_writes), number_of_bytes_to_transfer, write_buffer_test) != CSL_SOK)
{
if(MMC_read(mmcsdHandle, (number_of_writes), number_of_bytes_to_transfer, write_buffer_test) != CSL_SOK)
              while(1);
}

The above code passed for FALSE as well for a card that was previously failing.

Lali

Hi Lali,

So far we have not had a micro SD card fail with the below parameters being passed to the test function:

do_write_test_method(false, 512);

If our initial issue was somehow something to do with successive reads/writes with the micro SD card, I think this code path should have exposed the issue, but to date has not.

I don't think the successive reads/writes with the micro SD card are the source of the issue, but perhaps the constant changing of the mmctod or mmctor timeout registers?

Thanks,

Ben

Hi Lali,

We will test out and provide feedback.

Also, should MMC_config() only be called once?

I wasn't able to find anything in the documentation which provided any restrictions on this method other than MMC_open() should be called prior.

Thanks!

Ben

Hi Lali,

We brought up the idea of setting the timeout to the larger of the two (this way constantly setting them would not have to occur).

Is the constant setting of these registers somehow interfering with proper operation of the MMC peripheral?

Thanks,

Ben

Thanks Lali.

We've tested with only modifying the timeout registers at initialization and so far everything seems good.

We just want to make sure there is nothing else going on.

Ben

Hi Lali,

Thank you for all the support.

This current solution seems to successfully work around the issue so far.

We would like to be able to get to the source of the issue to make sure it does not appear again later down the road.

It does seem to have something to do with the constant setting of the TOD/TOR registers, but what could it be at the core?

Thanks,

Ben