MSC exception

Hi user85932,

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?

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.

Hi Einar, 

One more finding.

1.Plug the USB into the PC and create a new file from the PC

2. Disconnect the USB, and plug the USB into the PC again, the PC pops up the following message.

Thanks for the update. I do not have any news from my side atm.

Hi,

Have you had any progress on this issue on your side?

I had a meeting with the R&D team responsible for this yesterday, and the current state is that after a thorough inspection of the code we cannot see an issue with the blockdevice code that would result in the observed corruption. In other words, we cannot see by analysis, a code path that would result in this. This does not mean that we have ruled out that there is an issue.

As we are not able to reproduce the corruption itself, we suggest that we provide you with a modified library that has instrumentation to detect some unexpected changes/states/behaviors. Would you be willing to use that in our testing to help narrow down the issue?

Another hypothesis that came up was that there could be a reentrancy issue where you call from multiple interrupt contexts (into the blockdevice code. Could that be the case?

Hi Einar,

Thanks for the update.

user7377 said:

Have you had any progress on this issue on your side?

No，we haven't made any progress.

user7377 said:

I had a meeting with the R&D team responsible for this yesterday, and the current state is that after a thorough inspection of the code we cannot see an issue with the blockdevice code that would result in the observed corruption. In other words, we cannot see by analysis, a code path that would result in this. This does not mean that we have ruled out that there is an issue.

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.

user85932 said:

After the patch was applied, although this issue couldn't be reproduced, I found some unexpected write operation while connect to the PC.  

user85932 said:

One more finding.

1.Plug the USB into the PC and create a new file from the PC

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.

user7377 said:

As we are not able to reproduce the corruption itself, we suggest that we provide you with a modified library that has instrumentation to detect some unexpected changes/states/behaviors. Would you be willing to use that in our testing to help narrow down the issue?

Yes, of course. 

user7377 said:

Another hypothesis that came up was that there could be a reentrancy issue where you call from multiple interrupt contexts (into the blockdevice code. Could that be the case?

I don't think so. We do not use any RTOS, nor do we do any file operations in the interrupt service.

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.

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.

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.

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:

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;

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

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.