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

    I am really struggling to get consistent behavior on the data written using the FAT_FS system on the external flash chip. 

    You mentioned that you tested with BLE instead of the USB, right? And then the issue was not present?

    Have you tried to use the QSPI example (SDK\examples\qspi) together with the USB? It is a bit more hazzle, because it doesn't contain this file system. The issue is that the fatfs is an external library, and most of our developers are currently busy working on the nRF Connect SDK for the nRF91. 

    But you said that the issue was not present while using BLE + FAT_FS? Only when using the USB?

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Edvin,
    Thanks for continuing to look at this. 

    Yes, you're right. Currently I've implemented FAT_FS on an external flash chip, with the USB stripped out and have not experienced corruption issues. I am using NUS to grab data from the file system and send it over the air as a replacement for reading the file over USB. This method is working quite well.

    I haven't tried QSPI only with USB, but just normal QSPI did not have this corruption.

    With your testing were you able to reproduce a similar corruption using the method I've described?

    --Jeff

  • 0 in reply to Edvin

    HI, I got the same problem, 

    sdk :nRF5_SDK_15.2.0_9412b96  

    revision of the nRF52840 ： cortex-m4 nrf52840_xxAA 1024KB+4KB 256KB  PCA1005

     

    I took up the problem on

    https://devzone.nordicsemi.com/f/nordic-q-a/48535/problem-about-fatfs-and-qspi-on-nrf52840 

  • 0 in reply to junpu

    Hi, has the issue resolved?

  • 0 in reply to JeffW

    Jeff, Edvin,

    My test here is like NRF_BLOCK_DEV_QSPI_FLAG_CACHE_WRITEBACK This function has not been implemented well. I have mentioned a problem before, and fae told me that there is no problem and I will not follow up. You can help me to see if this Flag is the cause

    tks,

    Nandi

Reply
  • 0 in reply to JeffW

    Jeff, Edvin,

    My test here is like NRF_BLOCK_DEV_QSPI_FLAG_CACHE_WRITEBACK This function has not been implemented well. I have mentioned a problem before, and fae told me that there is no problem and I will not follow up. You can help me to see if this Flag is the cause

    tks,

    Nandi

Children
Terms of service