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

[ketiljo]

Can it be that the  USB port power is turned off after a while? There shouldn't be any difference in how Windows handles a USB drive across Windows versions. Check in Device Manager: 

[Mars_xu]

1. Test conclusion

1) I turn off the power saving option of USB hub power tube of win10 home version, and the test will still appear;

2. Other information:

1) The windows 10 home version is connected to the MCU of other four manufacturers without disk loss;

2) It can be determined that there is a difference between win10 home edition and win10 professional edition. Previously, we used MCU from other manufacturers to encounter disk loss in win10 home edition, which was finally solved by upgrading SDK;

3. Personal suggestions:

1) You find a win10 home computer, which is very easy to reproduce;

[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

[Edvin]

Hello DJJ,

I don't have any news on this front. 

Can you please explain to me the difference between usbd_msc_pca10056_abnormal.log and usbd_msc_pca10056_asset_failed.log? I see that the "abnormal" is the one that contains the "CMD: ATA PASS-THROUG". The other one does not. What is the difference?

I see that some logs are dropped. Is it possible to remove some of the logs that aren't essential? 

When do you get this CMD: ATA PASS-THROUG? Is it "immediately" after connecting the USB, or is it after the 20 minutes, when the usb device has stopped responding?

Can you please try to set breakpoints in the following places, to check whether they are hit, but the log is dropped:

1: Somewhere near the start of your application? E.g. where you print the "Reset reason". I want to double check that the device doesn't reset (even though you don't do it manually).

2: In the error handler. Please define DEBUG in your preprocessor definitions. Then set a breakpoint in app_error_handler_bare() in app_error.c (make sure that the APP_ERROR_CHECK() -> APP_ERROR_HANDLER() is pointing to this, after you add DEBUG in your preprocessor definitions). 

Then, approximately where in the log are you when the device stops responding? Is it the "CMD: ATA PASS_THROUGH"?

BR,
Edvin

[DJJ]

Hello Edvin,

It is my negligence to not explain the "asset failed" one to you. As mentioned in my last reply, I defined macro NRF_LOG_DEFERRED to 0 to solve the problem that lots of logs are dropped. However, it leads to asset failed finally. I exported the logs to usbd_msc_pca10056_asset_failed.log in case there is any useful information. It seems that I caused a confusion. I am sorry for that.

To solve the problem that a lot of logs are dropped, I have disabled some  statements (e.g. NRF_LOG_DEBUG("state: %d, ep out event, status: %d", p_msc_ctx->state, p_event->drv_evt.data.eptransfer.status);) which print the status of usbd. I repeat the test and export the logs to usbd_msc_pca10056_abnormal_0915_01.log. However, some logs are still dropped. So I disabled all the statements except these who begin with "CMD:" in app_usbd_msc.c. I repeat the test for another 3 times and the log files are named in sequence. Unfortunately, the problem is not solved totally. And I hope that there is no important information that is dropped. All the log files are attached. 

I have set breakpoints in the required places and run the program in debug mode with DEBUG defined. I am sure that there is no reset in the whole running period. And the function app_error_handler_bare() is never called. 

I confirm that the device stops responding when the "CMD: ATA PASS-THROUGH" is printed. After that, the logs are printed in a very slow speed and the logs are similar. You could verify this point by checking the logs after "CMD: ATA PASS-THROUGH". Moreover, I notice that  it spend less time to stop responding in debug mode than that connect to PC only. The device stops responding in 3, 8 and 13 minutes and the corresponding log files are "03", "02" and "04" respectively. If you connect the device to PC only, it will spend abort 20 minutes to stop responding.

I hope there is any information useful and could help you.

Yours,

DJJ

usbd_msc_pca10056_abnormal_logs.7z

[DJJ]

Hello Edvin,

I am wondering if there is any progress now? The issue is of great concern to us. I will appreciate it if you could pay some attention to it and kindly let me know if there is any progress.

Thank you in advance.

Yours,

DJJ

[Edvin]

Hello DJJ,
This ticket is not forgotten. Someone who worked on the USB drivers have been assigned to work on this. I have pinged him to ask whether he has found anything yet, but I have not yet received a reply yet. I will keep you updated as soon as I know more.

BR,
Edvin