Short config desc has wrong bDescriptorType (IDFGH-14788) #15526
Comments
github-actions
bot
changed the title
|
Hi @alex-k8 , could you try to increase Reset recovery delay to 500 ms and try again? This parameter could be found in menuconfig: Component config → USB-OTG → Hub Driver Configuration → Root Port configuration. |
|
Hey @roma-jam Thanks for the suggestion, however it seems to be doing the same thing. Judging by these two lines and the timestamp, I suppose I did set the value correctly, right? |
|
Hi @alex-k8, thanks for trying this, sometimes devices need a bit more time after reset to be able to return the Configuration Descriptor. But this is not our case. May I ask you to change the logic of getting short descriptor in the file esp-idf/components/usb/enum.c, line 370? Just replace the whole case with this: And share the output. You can share only the lines after tne Thank you. |
|
Thanks @roma-jam Still getting the same issue. It did return more bytes (zeros) so I suspect the change was successful, but I'm still getting the |
|
Hi @alex-k8 , thanks for the info. Yes, the device returns appropriate amount of bytes (91, which is 0x5B - right wTotalLengh value for Config Descriptor), but the questions is why the data is invalid. Do you have any chance to capture the Wireshark log while attaching this device to the PC Host? |
|
@roma-jam unfortunately I don't own the device, I'm getting the logs from my customer who is using my custom board. I can assist him in getting the logs if you can send me some high level instructions, or I can figure it out as well if needed. I have done it once in the past but it's been over a year. From my understanding, the short config response is used to store the wTotalLength value, and then that's used in the full config request? Couldn't we hardcode the 0x005B to see if it proceeds and works as expected after that step? |
|
@alex-k8 ,
yes, there is no information about the full length, so we request first 8 bytes (short), get the full length and then use this value to request the whole Configuration Descriptor.
We could, indeed, but that doesn't make any real sense, as this will be the same as request the maximum - 0xff (or 255) which we just tried.
I don't think that I will provide any better than the Wireshark themselves: https://wiki.wireshark.org/CaptureSetup/USB Then, it is better to filter the log, but if that is not possible by any reasons we can filter it on our side and get the information we need. So, both (filtered / non-filtered) are OK. If you need anything more precise, let me know. |
Oh I see, so it's actually passing the GET_SHORT_CONFIG_DESC and the issue is in the full descriptor? Thanks for the link, I will see what I can do and get back to you soon! |
|
in case to prevent any misunderstandings - there are no requirements for any additional hardware to capture the usb log with Wireshark: only the device itself and PC Host. Feel free to ask any questions in case they appear. Thanks for the understanding and collaboration. |
|
Yup, thanks @roma-jam . I had used it once before to figure out what the computer sends to turn on the caps lock LED on keyboards, so I'll figure it out. Thank you for your help. |
espressif-bot
added
Awaiting Response
|
Hey @roma-jam , I managed to get some Wireshark logs. Unfortunately they are not filtered, but the logs with ID 1.17.0 should be the relevant ones. Let me know if you need anything else from me. Github wouldnt allow me to upload the .pcapng file, so I zipped it. |
|
Thanks, log from the Host was from the High-speed port.....S3 has a Full-speed. That might be relevant. In the log the request configuration descriptor is done in two steps: first request is 9 bytes only, then - the We can try to do the same: change short amount from 8 to 9 bytes and check whether it helps. To do that, it is possible just to change the define in
|
|
Hey @roma-jam thanks for the quick response. Not sure what you mean by I did some tests by changing the ENUM_SHORT_DESC_REQ_LEN, but it didn't seem to help unfortunately. Below are the logs |
|
@alex-k8 ,
Yes, some device (maybe some old laptop, but I guess it should be really old, so maybe some other embedded device) with the port, that supports Full-speed. Because the keyboard has the usb-c connected and the behavior on Full-speed is quite strange: it reports the right amount of bytes, but no data. Based on the Wireshark log, there is no specific in the interaction. Also, could be the power problem. So let's exclude it: is there any chance to try connect the keyboard via external hub with the external power supply? UPD: I had read about the keyboard and there are some complains about it being not detected after loading to Win from BIOS. It requires to be turned-off and then turned-on with the switcher. So, if there is a power switcher on the keyboard we could try:
Please, let me know if any of this help or change the original behavior somehow. |
|
Hi @roma-jam thank you. I got some logs from a usb2 port, not sure if they are too much different. ID should be 1.2.0. Unfortunately no power hub is available. But my PCB operates both in power mode (through the type c) and through battery. Same issue on both. I read some things as well, but keep in mind this is the Air75HE and not the Air75. There is a switch that toggles between Windows/Linux/Mac, but unfortunately again it's the same issue on all. It doesn't seem to change anything, only some key bindings probably. There is no power switch. Thank you for taking time to look at this. |
Answers checklist.
IDF version.
v5.4.0
Espressif SoC revision.
ESP32-S3
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
Custom Board
Power Supply used.
Battery
What is the expected behavior?
I expect the enumeration and parsing to succeed successfully when connecting a USB Keyboard
What is the actual behavior?
Instead, I get the error
Short config desc has wrong bDescriptorTypeSteps to reproduce.
Debug Logs.
More Information.
I enabled verbose logs just in case it helps. I have tried many keyboards and this is the first that this occurs. Not sure if the short config is necessary? Might be just possible to skip it and it could be that this device does not support it for some reason?
Below are also logs from
USB Device Tree Viewerif it helps. Thank you very much!Edit: I noticed in the above logs it says version v5.5. Not sure why, but either way this error was happening on earlier and on latest versions, even on Arduino.
The text was updated successfully, but these errors were encountered: