nrf52840 usb_msc demo windos10 Home Edition USB disk will be lost in about 20 minutes

[Mars_xu]

I used usb_msc with nRF5SDK160098a08e2 sdk to connect the usb of pca10056 development board to win10 home version and the disk could not be recognized after about 20 minutes;

1. Current test conclusion:

 1) Appears only in win10 home edition, not in win10 professional edition;
 2) Use the Debug mode, the optimization level is set to None, the disk is displayed for 20 minutes after mounting, and the disk is not lost. When entering the secondary folder to write the file, the file cannot be written, and finally the disk is lost;

2. Test procedures

nRF5SDK160098a08e2-new-2.rar

3. Problem phenomenon
1) When the USB is connected to the computer

2) The disk is lost in about 20 minutes

4. Test method
1) Burn the compiled program
2) USB connection to win10 home version computer
2) Create TEST1/TEST2/test.txt

   
3) Write the current time in the test.txt file every 10 minutes;
4) After a few times you will find that the file cannot be written;
5) The disk has been lost;

5. The compiled hex file is convenient for you to quickly reproduce the problem;

 2425.usbd_msc_pca10056.hex

[Edvin]

Hello,

I noticed that the timestamp from your log isn't chronological? Do you know the reason for that? Is the nRF resetting when the log timer resets? If so, have you checked why it resets? By the way, are the timestamps from the logging module or your terminal?

One example of this is between line 9 and 11. Is this a reset, or just the app_timer/nrf_log acting funny?

Have you tried to print something in the log on startup, and see if that occurs when the log reset the timer?

If you have a reset, can you check the reset register on restart?

[Mars_xu]

[deleted]

[Edvin]

Hello,

I see that our R&D team is discussing whether or not they can spend resources (physical and time) to research this issue by installing the Windows version on a computer. 

In the meantime, they still struggled to understand the timestamp on the logs. Was the ATA PASS the last command issued from the USB host, or was there something after that? I am sorry if this is really obvious for you. It was not to us, unfortunately. 

From their last internal message:

"My suspicion is that there is another ATA-related command issued from Windows which we consider a fail. My candidate is the "ATA SENSE". On Google I found that some Linux versions check for SMART values every 10 seconds and this is my suspicion in this case. Maybe this Windows version does this check in a similar fashion.

Are there any other commands that are not handled? I can't see it from your logs, but I am not sure if there are any resets in the log or not.

BR,

Edvin

[Edvin]

Hello,

Did you check whether you had any resets during the runtime of the log? 

Our main suspicion is that there are still some unhandled USB events, but I don't see any NRF_LOG_DEBUG("CMD: UNSUPPORTED"), which would suggest an unhandled event in the log. Therefore, I want to know whether your log is from one take, or if you have snipped together several runs.

It would also be good if you write something like:

NRF_LOG_INFO("application start"); in the beginning of your application. Then you would know if you have any resets during the runtime.

Best regards,

Edvin

[DJJ]

Hello,

I am so sorry for our no response in the last two months. We spend a lot of resources on the development of new functions so that the issue is suspended. My apologies again and now it is the time to restart it. The issue was processed by  @Mars_xu but he is busy in other things, so I accept an assignment to take it over.

I have read all the replies and add required codes to /examples/peripheral/usbd_msc/. I repeat the test and capture the logs. All the logs are export to usbd_msc_pca10056_abnormal.log from Debug Terminal of SEGGER Embedded Studio for ARM V4.30b (64-bit) ("SES" for short). The modified source code files and the log file are attached.

I have searched the log file and find "CMD: ATA PASS-THROUGH" in it. Maybe this is what you want. And from there, the timestamps are out-of-order. I promise that I did not reset the development board (nRF52840-DK).

And you can see there are lots of "Logs dropped" in the log file. I have defined macro NRF_LOG_DEFERRED to 0 according to https://devzone.nordicsemi.com/f/nordic-q-a/43365/nrf_log-logs-are-dropped, but I get asset failed finally.

I am wondering if there is any progress in the last two months? Please kindly let me know. I will appreciate it if you could provide some additional suggestions.

Yours,

DJJ

usbd_msc_pca10056_debug.7z