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

    Filenames are stored on the QSPI memory just like file contents, so it is possible that there is a remaining bug in block_dev library other than what was fixed in the earlier thread. It is not a known issue though nor can we pinpoint it as this point.

    Can you say more about how early it occurs, and have you found a way to reliably reproduce it?

  • 0 in reply to user7377

    Hi Einar

    I can not find a way to reliably reproduce it so far, and the probability of this happening is very low. It may have happened before this thread, but I'm not 100% sure.
    I believe that there is a bug in block_dev library because I am able to capture the debug logs sometimes.
    By the way, the latest SDK did not fix the issue mentioned in this thread.

  • 0 in reply to user85932

    Hi,

    greyorbit said:
    What I understand so far, this issue likely occurs while connecting to the PC and copying files to the MSC from the PC side. Our products can be upgraded by copying the firmware to MSC. I have asked our test team to check the MSC before and after the upgrade, it's still being tested.

    It will be interesting to learn the result of that test.

    greyorbit said:
    Have you fixed these problems? They can be reproduced on the Nordic DK. I think if these are fixed, this issue will probably be fixed.

    I was not able to reproduce the issue with warnings on Windows on my side, but I managed once to get a corrupt file while coping new files, disconnect, reconnect, copy new file, etc. I agree it seems reasonable that the same root cause can be the cause of all this though we cannot say for sure at this point.

    I will let you know when the team investigating this have any progress, if they have any questions and when they have some code we would like you to test.

  • 0 in reply to user7377

    Hi,

    user7377 said:
    I was not able to reproduce the issue with warnings on Windows on my side

    I test on the Windows 10 Pro. I can also reproduce this problem in another product that is not developed by us, and it also uses NRF52840.

  • 0 in reply to user85932

    Hi Jason,

    We have not got to the bottom of this yet, but we have a fix that may be relevant. This is a change in app_usbd_msc.c:

  • 0 in reply to user7377

    Hi Einar,

    Thanks for the update.

    Do I need to add a timeout for the while loop?

    I have encountered many times that the device hangs in the while loop of the USB module.

    In my current code, I added a timeout for the while loop.

    --- nrf_block_dev_qspi.c-rev7574.svn001.tmp.c	 
+++ nrf_block_dev_qspi.c-rev7575.svn001.tmp.c
@@ -289,2 +289,2 @@ static void qspi_handler(nrf_drv_qspi_evt_t event,
-
-static void wait_for_idle(nrf_block_dev_qspi_t const * p_qspi_dev)
+#include "rtc.h"
+static ret_code_t wait_for_idle(nrf_block_dev_qspi_t const * p_qspi_dev)
@@ -291,0 +292,2 @@ static void qspi_handler(nrf_drv_qspi_evt_t event,
+	time_t startTick, currentTick;
+	startTick =  RTC_getTimeTick();
@@ -294,0 +297 @@ static void qspi_handler(nrf_drv_qspi_evt_t event,
+		/*The watchdog timer stop in WFI mode, it will be wakeup by any interrupt*/
@@ -295,0 +299,6 @@ static void qspi_handler(nrf_drv_qspi_evt_t event,
+		currentTick =  RTC_getTimeTick();
+		/*wait for 3 seconds*/
+		if(currentTick > (startTick + 3))
+		{
+			return NRF_ERROR_TIMEOUT;
+		}
@@ -296,0 +306 @@ static void qspi_handler(nrf_drv_qspi_evt_t event,
+	return NRF_SUCCESS;

    --- diskio_blkdev.c-rev7578.svn001.tmp.c	
+++ diskio_blkdev.c-rev7579.svn001.tmp.c	
@@ -43 +43,4 @@
-
+#define DISKIO_MSC_LOG
+#ifdef DISKIO_MSC_LOG
+#include "log.h"
+#endif
@@ -82 +85,2 @@ static void block_dev_handler(struct nrf_block_dev
-static void default_wait_func(void)
+#include "rtc.h"
+static INT default_wait_func(BYTE drv)
@@ -84 +88,14 @@ static void block_dev_handler(struct nrf_block_dev
-    __WFE();
+	time_t startTick, currentTick;
+	startTick =  RTC_getTimeTick();
+    while (m_drives[drv].busy)
+    {
+		/*The watchdog timer stop in WFI mode, it will be wakeup by any interrupt*/
+        __WFI();
+		currentTick =  RTC_getTimeTick();
+		/*wait for 5 seconds*/
+		if(currentTick > (startTick + 5))
+		{
+			return 1;
+		}
+    }
+	return 0;

  • 0 in reply to user85932

    I do not immediately see that it would be needed, but it should not hurt either provided the timeout is not too short.

Reply Children
Related
Terms of service