• State Not Answered
  • Replies 42 replies
  • Subscribers 26 subscribers
  • Views 3303 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
  • 0

    Hi,

    There is a bug in the QSPI backend where it does not handle all possible states when configured in writeback mode. This can cause files to be corrupted, and might be what you are experiencing. The fix for this is to modify nrf_block_dev_qspi.c from SDK 17.0.2 (located in SDK/components/libraries/block_dev/qspi/). See the diff below for what changes to make:

    @@ -715,7 +715,9 @@ static ret_code_t block_dev_qspi_write_req(nrf_block_dev_t const * p_blk_dev,
     }
     else
     {
-        if (p_work->writeback_mode)
+        if (p_work->writeback_mode &&
+            p_work->erase_unit_idx != BD_ERASE_UNIT_INVALID_ID &&
+            p_work->erase_unit_dirty_blocks)
         {
             ret = block_dev_qspi_write_start(p_qspi_dev);
         }

    This should also work for older SDK versions, but has only been tested with SDK v17.0.2.

    Best regards,

    Marte

Reply
  • 0

    Hi,

    There is a bug in the QSPI backend where it does not handle all possible states when configured in writeback mode. This can cause files to be corrupted, and might be what you are experiencing. The fix for this is to modify nrf_block_dev_qspi.c from SDK 17.0.2 (located in SDK/components/libraries/block_dev/qspi/). See the diff below for what changes to make:

    @@ -715,7 +715,9 @@ static ret_code_t block_dev_qspi_write_req(nrf_block_dev_t const * p_blk_dev,
     }
     else
     {
-        if (p_work->writeback_mode)
+        if (p_work->writeback_mode &&
+            p_work->erase_unit_idx != BD_ERASE_UNIT_INVALID_ID &&
+            p_work->erase_unit_dirty_blocks)
         {
             ret = block_dev_qspi_write_start(p_qspi_dev);
         }

    This should also work for older SDK versions, but has only been tested with SDK v17.0.2.

    Best regards,

    Marte

Children
Related
Terms of service