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 Jeff,

    Thank you for reminding me. I have forwarded this issue to the team that developed this example, but I haven't received any response yet. I tried to push this issue up today, and was tipsed to contact one guy directly, but he will not be in the office until tomorrow. Hopefully, I can get back to you tomorrow with some new information.

    BR,

    Edvin

  • 0 in reply to Edvin

    Hey Edvin,

    Just checking in again with the Nordic team if any progress has been made on this front.

    Thanks,
    Jeff

  • 0 in reply to JeffW

    Hello Jeff,

    Unfortunately I don't have an answer to you yet. The person looking at this has concluded that it isn't related to the USB part of the application, but the file system. Using strcmp() reveals that the record is corrupted, and this is before the USB is connected. Still trying to figure out why the record is corrupted, and whether it is possible to detect it without using the strcmp() to check all the records.

  • 0 in reply to Edvin

    Edvin,

    Unfortunately having a problem in the file system seems to be more of a problem to my product then originally suggested!

    Is it possible this is the same issue as outlined in this post?
    https://devzone.nordicsemi.com/f/nordic-q-a/41792/fatfs-qspi-usbmsc-bug

    Would you expect Nordic to have a fix for this in a timely fashion? Or should I abandon the file system?

    Appreciate the help,
    Jeff

  • 0 in reply to JeffW

    In that thread rc766437 suggested:
    "I think it is the same problem, just modify the QSPI block driver code<nrf_block_dev_qspi.c>, let the write/read buf pointer address aligned 4 bytes."

    I have come across a few examples of people running into this issue, but haven't been able to find the correct spot to 4 byte align the buffer.
    https://devzone.nordicsemi.com/f/nordic-q-a/38156/qspi-read-fail/

    Any insight on this?

  • 0 in reply to JeffW

    Edvin,

    Nothing fruitful on my end from this, as the serial flash should be able to deal with single byte accesses. 

    Any update from Nordic? Surely I am not the only one running into issues with file system implementations.

    Thanks,
    Jeff

Reply
  • 0 in reply to JeffW

    Edvin,

    Nothing fruitful on my end from this, as the serial flash should be able to deal with single byte accesses. 

    Any update from Nordic? Surely I am not the only one running into issues with file system implementations.

    Thanks,
    Jeff

Children
  • 0 in reply to JeffW

    Hello Jeff,

    I got an answer from one of our SDK engineers. He wrote the following:

    ----------------------

    I've tested it using attached code, but I did not manage to get it working. In provided code f_printf is called from irq context, while internally it is waiting for interrupt from qspi and without proper irq priorities it hangs.

    I modified example to write to file from main loop, and it seems to be working on nRF52840 DK 1.0.0, I don't get any corrupted data tested up to 4500 records. Please check example with attached code (nonirq_main.c) if data still gets corrupted.

    ----------------------

    Attached is the noirq_main.c file that he used for testing. Can you please try it and see if it works better?

    Fullscreen noIRQ_main.c Download

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Edvin,

    I'm still get corruption running the SDK engineers code. Near the 1905th byte this time (~132nd record). Ran the test twice from my end with the same corrupted results. 

    Regards,
    Jeff

  • 0 in reply to JeffW

    Hello Jeff. Did you try the main.c file in your project, or an unmodified usbd_msc example from SDK15.2.0? Can you try with an unmodified version of this example? And to be completely sure, unzip a fresh copy of SDK15.2.0

    I did the same test, and I do not get the corrupted messages with this example. Please note that this example doesn't by default delete the old file, so connect the device with the usbd, and delete the LOG_DATA.txt file. Also note that some .txt readers cache the old files, so make sure to close this file (e.g. if you use notepad/notepad++), and then re-open it to see the latest version.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Edvin,

    On the first nRF52840 development kit I was using the corruption still occurred when using the provided noirq example. A second development kit seemed to work up to the 5000 records I tested, but it still seems pretty flakey. When re-running the test (deleting the file and restarting) on the 2nd board, I sometimes did see corruption of a very long string of ÿ's in the beginning/middle of the log.

    When re-testing the first development kit, I noticed the fatfs_ls function returned this:

    After re-formatting the drive using Windows it seemed to get rid of this, and the corruption didn't happen the next test.

    It seems that removing the writes from an interrupt base has sometimes helped us pass over the first discovered 13825th byte boundary, but this solution does not work all of the time. 

    Attached is a corrupted file with the noirq code:

    Fullscreen test_log1.txt Download

    I appreciate the help, It looks like we are making some progress but this still needs a little more attention,
    Jeff

  • 0 in reply to JeffW

    JeffW: Please let us know what is version of your DK?

Terms of service