topic Re: sdcard read/write data corruption in MQX Software Solutions

sdcard read/write data corruption

keno — Wed, 26 Nov 2014 17:08:43 GMT

My environment: Vybrid custom board based on twrvf65gs10_a5, MQX 4.1.1, IAR toolchain

I see others have experienced similar problems when reading from / writing to the sdcard. In my particular case we are compiling for a ddr target and then transferring the binary to the target sdcard using the MQX FTP server. Occasionally (about 1 in 10-15 times) the file will be corrupted and is isolated to a contiguous block of 32 bytes occurring at various address locations within the file. I've attached diff snapshots which show the 32 byte blocks that are corrupted during 3 different occurrences. A corruption also sometimes occurs when the bootloader copies the binary from the sdcard into ddr which is caught by the md5 checking in the bootloader. I have not yet evaluated what gets corrupted during a copy from sdcard to ddr.

My suspicion was that it may be cache related since the corruption occurs within a 32 byte block. I noticed the MQX 4.1.1 release notes mentioned a couple resolved issues (MQX-1445, MQX-4216) that could be related however the problem still occurs after transitioning from 4.1 to 4.1.1.

Is anyone else using the sdcard and getting consistently reliable operation?

Any other info or testing that would help further diagnose the issue?

Re: sdcard read/write data corruption

alejandrolozan1 — Thu, 27 Nov 2014 17:53:13 GMT

Hi,

Have you been able to reproduce this error in one of our boards. I have not seen this problem before, therefore it would be nice to reproduce the issue in one of our boards so we can test it and narrow down the possible problem.

Best Regards,

Alejandro

Re: sdcard read/write data corruption

keno — Mon, 01 Dec 2014 13:59:26 GMT

Hi Alejandro,

I have not attempted to reproduce the problem on the tower board yet. I'll work on getting it setup and give it a try.

-Ken

Re: sdcard read/write data corruption

KenOverly — Thu, 15 Jan 2015 20:44:35 GMT

alejandrolozano,

I was able to reproduce this problem on a TWR-VF65GS10 rev G board running our application. I've migrated from MQX 4.1.1 to 4.1.2 since my last post however the problem occurred in both.

My development environment is IAR toolchain 6.60, MQX 4.1.2 for Vybrid.

Thanks,

-Ken

Re: sdcard read/write data corruption

alejandrolozan1 — Thu, 22 Jan 2015 21:44:28 GMT

Hi Ken,

Sorry for the delay. I wonder if it is possible for you to share your application.

That way I test and try to find out the problem.

Best Regards,

Alejandro

Re: sdcard read/write data corruption

KenOverly — Tue, 27 Jan 2015 13:14:45 GMT

Hi Alejandro,

Thanks for your reply. I've requested permission from my manager to share our application code. Is there a way I can send it to you privately?

If I'm unable to send our application I may be able to modify a Freescale example project to demonstrate the issue I'm having.

Thanks,

-Ken

Re: sdcard read/write data corruption

alejandrolozan1 — Wed, 28 Jan 2015 17:06:17 GMT

Hi Ken,

Sorry for the delay. I wonder if you can create a Service Request in www.freescale.com/support.

There you can upload your project and it is not public.

Best Regards,

Alejandro

Re: Re: sdcard read/write data corruption

KenOverly — Mon, 02 Feb 2015 16:01:41 GMT

Hi Alejandro,

I have some new information to report. I noticed this forum post which is similar to the problem I'm experiencing though it's on the K70FX platform (mine is Vybrid). It prompted me to look at the sdcard driver and investigate a little deeper. One observation I made recently was that the frequency of the data corruption seems to be affected by ethernet communication activity. Few errors occur with the network cables left disconnected but would immediately increase once the network cable was connected on both our board and the TWR board. The test I'm performing continually reads a 1MB file from the sdcard and performs an MD5 checksum of the file which it then compares with the known checksum - roughly once a second. I've found that with network communication active it fails about 30% of the time.

As a test I modified the sdcard driver to disable interrupts while data was being copied to/from the sdcard dma buffer. The result was that it significantly reduced the number of errors (6 errors in 330,000 file reads).

Here is the portion of the code that I modified in esdhc.c:

In esdhc_read() beginning at around line 1554:

#if ESDHC_IS_HANDLING_CACHE
    _int_disable();


    if (head_len)
    {
      _DCACHE_INVALIDATE_LINE(head);
      _mem_copy(head, data_ptr, head_len);
    }


    if (body_len)
    {
        _DCACHE_INVALIDATE_MBYTES(body, body_len);
    }


    if  (tail_len)
    {
      _DCACHE_INVALIDATE_LINE(tail);
      _mem_copy(tail, ((uint8_t *)data_ptr) + head_len + body_len, tail_len);
    }


    _int_enable();
#endif
    {
      _DCACHE_INVALIDATE_LINE(tail);
      _mem_copy(tail, ((uint8_t *)data_ptr) + head_len + body_len, tail_len);
    }

In esdhc_write() beginning at around line 1692:

    _int_disable();
   
    /* Flush caches */
    if (head_len)
    {
        _mem_copy(data_ptr, head, head_len);
        _DCACHE_FLUSH_LINE(head);
    }


    if (body_len)
    {
        _DCACHE_FLUSH_MBYTES(body, body_len);
    }


    if (tail_len)
    {
        _mem_copy(((uint8_t*)data_ptr) + head_len + body_len, tail, tail_len);
        _DCACHE_FLUSH_LINE(tail);
    }


    _int_enable();

Re: sdcard read/write data corruption

jonny — Wed, 05 Aug 2015 10:03:33 GMT

Hi,

did you find anything more out about this or find a solution?

Thanks

Jon

Re: sdcard read/write data corruption

keno — Thu, 10 Mar 2016 19:03:41 GMT

Jonathan,

Sorry it took me so long to respond. I did not notice your post until today. Unfortuantely I have not found a solution to this problem.

Per Alejandro's request I created a Freescale support request (SR#1-3639496941 for reference). I modified the Freescale SDCARD demo application and was able to reproduce the problem on the Vybrid TWR board. I attached that modified demo to the SR and Alejandro was unable to reproduce my results. The suggestion was that perhaps I had modified the BSP or user_config.h which created the problem I was observing.

That was as far as I was able to chase it.