USB Host MSC: USB thumb drive cannot be initialized (IDFGH-13412) #14319
Assignees
Labels
Resolution: Done
Issue is done internally
Status: Done
Issue is done internally
Type: Bug
bugs in IDF
Comments
github-actions
bot
changed the title
|
Hi @rikaiot, Is that possible to change the verbosity level to
|
|
Hi @roma-jam, here is the verbose log output, when starting the example and plugging in the USB thumb drive: |
|
@rikaiot thanks for the additional information. Which port do you use to power the dev kit with attachable USB drive? There might be not enough power to support both devices. |
|
@roma-jam we tried powering the dev kit via a hub with external power supply without any difference. We additionally also tried directly powering the USB thumb drive with an separate 5V power supply unit but the error persists. The interesting thing is, that the example is working when the thumb drive is already plugged in at startup. |
|
@rikaiot , Could you please share the same log but for the case when device is present in the port while dev kit is powering up? Also, do you know how to use Wireshark and how to log USB traffic with it? To get the log of attaching USB Drive to the PC Host also will be helpfull. |
|
@roma-jam, Here is the log of a run with the thumb drive connected while powering up the kit.
We are not familiar with capturing USB traffic with Wireshark but could try to figure it out. But we would also be glad to send you 5 pieces of the affected thumb drives to allow you to reproduce and investigate the issue directly. |
|
@rikaiot Let's try to increase the Please, let me know about the result. |
|
@roma-jam thanks for the suggestion, we have tried increasing the Reset recovery delay to 500ms and also to 5000ms but we could not see any change in the behavior. It still works when the stick is connected and the dev kit is resetted or rebooted but not when hot-plugging the thumb drive. |
|
Hi @rikaiot, Based on the logs you provided, the USB Host lib part itself enumerated the device and pass it to the MSC Host class driver without any issues. Then, when the class driver tries to get the unit ready state (via test_unit_ready command), the USB thumb driver responded with the Currently, the MSC Class driver doesn't request the sense status every time after something went wrong (meanwhile, we added that: espressif/esp-usb#34, but without a release yet), so maybe some additional logic is required while the device is hot-plugged. To understand the reason, it is necessary to have the log. Thanks. |
|
Hello @rikaiot , thanks for the useful logs. Could you try increasing this to 5000 or even 10000 ms? (You will have to move the code from managed_components/espressif__usb_host_msc to components/espressif__usb_host_msc , as our build system does not allow modifying files in cc @leeebo I think you encountered similar problem in the past... |
|
@tore-espressif We had issues with some specified USB disks, which were fixed by increasing the RESET_RECOVERY_MS from 20 to 500ms. @rikaiot Which version of usb_host_msc component you using? Does the USB Disk you using work as normal on PC ? |
|
Thank you @tore-espressif but increasing WAIT_FOR_READY_TIMEOUT_MS to 5000 or 10000 did not solve the problem. Thank you @roma-jam is there a way to send you some of our thumb drives so you are able to reproduce the issue directly? it might be good to have some test devices for testing future releases anyway. |
espressif-bot
added
Status: In Progress
|
I tried two USB drives I had on hand, one being an SD card reader and the other a regular USB drive. The card reader USB encounters the issues mentioned above when used with ESP32- IDF versions 5.3, 5.2, and 4.4, whereas the regular USB drive works fine. When I attempted to use STM32CubeMX to generate an MSC project for the STM32F105RCT6, both the card reader USB and the regular USB drive worked without any problems. It seems that the MSC compatibility in ESP-IDF might not be very good. Increasing the delay with the
|
|
@createskyblue Thanks for the test! We never claimed compatibility with SD card readers, but this is surely a feature we will add |
|
@tore-espressif the initial issue happens with regular USB thumb drives. Is there a way we could send you some test devices to elaborate the issue? |
Hello @rikaiot please contact me at [email protected] and we can handle the rest via email. |
|
I have the same problem. My device is not a SD card reader, it is an USB thumb drive. As long as I know, some USB thumb drive actually is a SD card reader with a permanent SD card inside. Please acknowledge me for any progress. |
|
@tore-espressif @roma-jam We are also having the exact same issue with a 16GB Lexar flash drive and do not want to ship until this is resolved. Since this doesn't look like it is going to be fixed anytime soon, can you give us a hint about what function(s) need to be modified in what file(s)? Changing the timeouts has no effect on the problem. Pulling the current master branch (1.1.3) doesn't fix the problem either. Here is the USB flash drive that doesn't work |
|
Hi @fozzzgate, thanks for reporting. Do you have an option to get the wireshark log of attaching such device to a PC? |
|
@roma-jam Yes, I also have the Attached are Wireshark captures of a good SanDisk Cruzer U 16GB USB drive insertion and a bad Lexar JumpDrive 16GB USB drive insertion. Wireshark Insertion Captures.zip The first difference is Frame 45: Good: Transfer length = 8, CDB (12 bytes): a20000000000000000080000 The Despite it saying |
|
@roma-jam @tore-espressif Attached are Wireshark JSON packet dumps of the bad (Lexar) and good (Sandisk Cruzer U) insertions. I have removed the "noise" between the two captures (i.e. timestamps, GUIDs) to make diffs easier. The dumps are virtually identical up to Frame 56, where the 'bad' Lexar drive returns For the 'good' Cruzer drive, Frame 56 returns |
|
This Stack Overflow answer seems to hint at a solution: Android SCSI USB communication issues |
fozzzgate
added a commit
to fozzzgate/esp-usb
that referenced
this issue
Oct 27, 2024
Fix for /espressif/esp-idf issue #14319 (espressif/esp-idf#14319). When TEST UNIT READY, some USB Drives and SD Card Readers respond with sense_key: 0x06, code: 0x28, qualifier: 0x00 (NOT READY TO READY TRANSITION - MEDIA CHANGED). In order to clear this code, a REQUEST SENSE needs to be performed before repeating TEST UNIT READY. If the unit is ready, there is a quick return from the msc_wait_for_ready_state function. The previous code caused a minimum 100ms delay before returning, even if the MSC device was ready. Also, the WAIT_FOR_READY_TIMEOUT_MS was increased to 5000ms, because some USB Drives were timing out with the old value of 3000ms.
|
Created pull request that fixes the issue: espressif/esp-usb#81 |
espressif-bot
added
Status: Reviewing
6 tasks
espressif-bot
added
Status: Done
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
V5.3
Espressif SoC revision.
ESP32-S3 (QFN56) (revision v0.1)
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
CMD
Development Kit.
ESP32-S3-DEVKITC-1-N32R8V
Power Supply used.
USB
What is the expected behavior?
When running examples\peripherals\usb\host\main\msc_example_main.c a the example is waiting for an USB thumb drive to be connected and after connecting some tests are performed on the thumb drive.
What is the actual behavior?
Some USB thumb drives cannot be initialized and generate an error and force the example to reboot:
The example is only working, when the USB thumb drive is already connected at startup of the example or when pressing the Reset button while the USB thumb drive is already connected.
Steps to reproduce.
Debug Logs.
More Information.
Further investigations showed that the example is hanging in msc_host.c in function msc_host_install_device on the location:
MSC_GOTO_ON_ERROR( msc_wait_for_ready_state(msc_device, WAIT_FOR_READY_TIMEOUT_MS) );
It seems that the thumb drive never gets into ready state. Increasing WAIT_FOR_READY_TIMEOUT_MS to a very long time does not help.
Interestingly it is working without error, when the USB thumb drive is connected at startup, so after the reboot the example is working. Only "hot-plugging" the thumb drive generates the error.
The issue also only occurs with some specific thumb drives other drives are working without problem.
Unfortunately we have a lot of these USB thumb drives in the field, as they were bundled with our products.
We could provide you examples of the affected USB thumb drives to solve the issue at anytime.
Here is the the device information outputed by the example when the thumb drive is connected at startup:
The text was updated successfully, but these errors were encountered: