• State Not Answered
  • Replies 42 replies
  • Subscribers 26 subscribers
  • Views 3316 views
  • Users 0 members are here
Attachments (10) Download All
Nordic Case Info
  • Case ID: 267337
Options

MSC exception

user85932

Hi,

Our production uses NRF52840 as the master chip. We encountered a strange problem where two folders have the same name and a file name has illegal characters. 

The probability of this happening is very low, so we can not find the root cause so far. As we know, the file system does not allow a folder with the same name and a file name with illegal characters. What are the possible causes of this problem?

The normal directory structure is shown below.

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

I would like to provide more details for the MSC issue as below.

I attached the nrf_block_dev_qspi.c that I used, you may diff with the original file of the SDK.

There are two major modifications.

1.the issue was reported in this link https://devzone.nordicsemi.com/f/nordic-q-a/36654/usbd_msd-disk-initialization-fails-in-usb-unplug-with-sdk15-0

the difference was I added a timeout for the wait_for_idle()  function because I found it would hang on this function sometimes.

2. add debug message for troubleshooting 

We got the debug log sometimes(please find debug.log), although everything looks good, I thought it was unexpected. 

By the way, there were not any debug logs when the issue "two folders have the same name and a file name has illegal characters"  occurred.

Parents Reply Children
  • 0 in reply to user85932

    Does that mean it has happened only once or multiple times? I think we need to find a pattern and a way to reproduce in order to proceed.

  • 0 in reply to user7377

    So far, it has happened more than 10 times on different devices(We have about thirty devices on hand), and four times in the last month.
    I would like to confirm if the debug log I caught is expected. What I understand, it is unexpected.
    From a code perspective, I think this is also due to unexpected write operations, just like this thread we reported before.
    As it is difficult to find a pattern to reproduce it. Is it possible to find out the root cause by code review(nrf_block_dev_qspi.c)？

  • 0 in reply to user85932

    Hi,

    I agree the debug log looks unexpected and indicates an issue. But I do not  understand the issue enough to say much. I have asked for input from the maintainers and will inform you of any updates. Please let me know any new findings you may have in the mean time, especially if you find a good way to reproduce the issue.

    Update:

    The team has reviewed the code and do not see any good way forward without having a method to easily reproduce the issue. There are a few things we would like to know, though (which again makes more sense when able to reproduce):

    1. What other components (e.g. SoftDevice) are used alongside filesystem in the application that could cause race conditions?
    2. In case there are many other components used alongside filesystem, if your could disable them temporarily and then check out whether the filesystem issue still occurs.
    3. Can you somehow log all of the file operations that are performed? Then we could try to reproduce on our end using this log.
  • 0 in reply to user7377

    1.What other components (e.g. SoftDevice) are used alongside filesystem in the application that could cause race conditions?

    ->Our production is a bicycle computer, the main system chart is below. The UART uses the DMA mode.

    2.In case there are many other components used alongside  filesystem, if you could disable them temporarily and then check out whether the filesystem issue still occurs.

    ->Sorry, it is difficult to disable other components. 

    3.Can you somehow log all of the file operations that are performed? Then we could try to reproduce on our end using this log.

    ->Actually, our system log included the log of all of the file operations that are performed, but I couldn't see any obvious log related to this issue.

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

    I attached the log of another two devices that have a similar issue.

    The app_error.log file records the function that returned the error.

    1.Please find the logs in the app_error.log file. There are some errors related to the file open and delete operation. it just due to the file with illegal characters. (Our system will delete the file that the suffix is not '.fit '  after unplugging the USB)

    2.

    AE-0.28-1609462306-usb_msc_module.c-USBD_fatfsUninit-398-0x1

    ->this log is due to the error while un-initializing the FATFS.

    The other logs due to the unexpected folder.

    According to the log file, I think these logs were caught after this issue happened.

    I attached the fatfs we used, the long file name and the timestamp was enabled.

     

  • 0 in reply to user85932

    Hi,

    Can you explain the logs, perhaps share the code that writes it? I would guess that the last number is the return value from the function, but about the first? Please explain.

    user85932 said:

    2.In case there are many other components used alongside  filesystem, if you could disable them temporarily and then check out whether the filesystem issue still occurs.

    ->Sorry, it is difficult to disable other components. 

    To be frank there is little to go on here, so I think it is important to try to narrow down the issue even though it might seem a bit tedious.

    user85932 said:
    I attached the fatfs we used, the long file name and the timestamp was enabled.

    It does not seem relevant but as this is not something we have used it would be interesting to know if you can reproduce the issue without as well (so _FS_NORTC and _USE_LFN both set to 0)?

Related
Terms of service