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

  • 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.

  • 0 in reply to user7377

    Hi Einar,

    user7377 said:
    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:

    Unfortunately, I have applied the patch, but it could still happen.

  • 0 in reply to user85932

    I see. The team is continuously looking into this and we have some ideas. I will update this thread when we have something worth sharing.

  • 0 in reply to user7377

    We are wondering if it is possible to rule out the MSC class as responsible for the issue or not. In your test, where you sometimes manage to get the corrupt data, we wonder if you can do some adjustments in order to narrow it down:

    • prepare/modify a FW that reproduces the issue
    • connect the DK to the PC via the JLink USB port
    • flash the FW
    • let the FW run until the issue occurs - so basically FW needs to have some way of validation when the corruption happens. Never connect the nRF52840 USBD port to the PC so MSC class never drives the block_dev.

    Is that possible?

Related
Terms of service