Attachments (6) Download All
Nordic Case Info
  • Case ID: 215258
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

USB MSC Corruption

JeffW

Hello,

I have been experiencing corruption using a similar implementation to the USBD_MSC example. Even after the various SDK fixes suggested to the same problem outlined in the forum.

I have edited the example to use a repeating timer with the scheduler to write an incrementing index, and two random numbers to a log_data.txt file.

i.e. sprintf(log_record, "%d,%d,%d\r\n", record_number,rand(),rand());

1,3542,16169

2,16521,11936

3,6713,17489

etc...

However, randomly in the log, symbols such as ' ' will replace anywhere between 8 and 18ish lines of data with symbols.

Using FATFS, the first few lines of a log was randomly being deleted/replaced with these non-characters, and symbols.

Upon switching to exFAT, as suggested by another user, the corruption still occurs, but somewhere in the middle of the log.

I have included the application for the nRF52840 DK with my function 'log_data_write_handler'.

Running this on the PCA10056 will create a log every 500ms. It is very reproducable that I have corruption happen anywhere between 200 and 1000 logs in. The corruption is shown in corrupt_log.txt by line 854.

Fullscreen corrupt_log.txt Download
usbd_msc.zip

Any help would be appreciated as the same problem is occuring on an audit trail for a production unit.

Thanks,

Jeff

Parents
  • 0

    Hello,

    Could you please specify what SDK you are using?

    Can you check the return value of f_printf, and see if you get any deviation when the broken records are written?

    BR,

    Edvin

Reply
  • 0

    Hello,

    Could you please specify what SDK you are using?

    Can you check the return value of f_printf, and see if you get any deviation when the broken records are written?

    BR,

    Edvin

Children
  • 0 in reply to Edvin

    Edvin, 

    Testing done on SDK 15.2.

    I tested f_printf for a return of <0 and did not get a breakpoint when corruption occurred on the 855th record. 

    I had also checked for non-printable characters and ram corruption with no success.

    It would appear the problem is deeper than that.

    --Jeff

  • 0 in reply to JeffW

    Jeff,

    Does the error occur on the same place in the log every time?

    I tried to run your project but I were some times not able to open the log (It said that it was corrupted), and when it worked, it only showed some weird symbols on the first line. What do you use to open the txt file?

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Edvin,

    No, the error/corruption does not appear in the same place every time.

    Please press button 3 on the SDK to reformat while the application is running, and not plugged into USB to run fatfs_mkfs(). This will reformat the FLASH chip as exFAT and reset the counter.

    I am using SES's RTT to output the record #.

    I am using notepad on windows to open the file.

    Please let me know if you have more issues. 

    --Jeff

  • 0 in reply to Edvin

    Edvin,

    Just to expand on your first question, on my 50 production units, I have tried to find a pattern/reason for how the corruption happens for weeks to no discernable results. Sometimes it happens around the same log number, other times in a completely different location. Most of the corruption edits 10 lines of the data_log. However, I have seen 8-22+ lines be 'erased' with some valid data, some symbols intermixed.

    I wanted to share this project with the Nordic team as a very reproducible example of corruption in hopes of coming to a solution. I appreciate the effort, and am willing to work further into finding a solution as this data log is an integral part of my product. 

    --Jeff

  • 0 in reply to JeffW

    Hello Jeff,

    I am sorry for the late reply. I will look more into this tomorrow. I have been able to reproduce what you describe, but I haven't yet found out why, or how to prevent it.

    Best regards,

    Edvin

Terms of service