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