Not all USB keyboards are detected by USB HOST library

[sraposo]

Purpose: a system that will accept data entry from an USB standard keyboard.

SoC: ESP32-S3

IDE: ESP-IDF 5.22

Program: based on "hid_host_example" example project from Espressif.

Problem: it was noticed that two generic USB keyboards with cable are NOT detect by USB HOST library most of times, while a wireless USB keyboard is ALWAYS detected (and enumerated). The 2 wired keyboards are fully operational when connected to a PC running Windows 10.

Connecting one of the wired keyboards, USB HOST prompts ("Default log verbosity" set to "Error"):
E (2895) HUB: Bad transfer status 1: CHECK_ADDR
E (2895) HUB: Stage failed: CHECK_ADDR

ESP_LOGx messages identified with "HUB" come from "hub.c", located at "(...)\esp\v5.2.2\esp-idf\components\usb\"

When verbosity set to "Debug", it returns:
E (1700) esp_timer: Task is already initialized
D (2010) HUB: Root port reset
D (2010) HUB: Stage done: START
D (2010) HUB: Stage done: GET_SHORT_DEV_DESC
D (2010) HUB: Stage done: CHECK_SHORT_DEV_DESC
D (2070) HUB: Stage done: SECOND_RESET
D (2070) HUB: Stage done: SET_ADDR
E (2070) HUB: Bad transfer status 1: CHECK_ADDR
E (2070) HUB: Stage failed: CHECK_ADDR
D (2080) HUB: Stage done: CLEANUP_FAILED

A lot of experiments (introducing delay, changing install function parameters, modifying priority on tasks...) were tried and no one was successful on solving the problem.

Incidentally, when "Default log verbosity" (menuconfig) was set to "verbose", problem definitely stopped: wired keyboard could be be detected and enumerated 100% of time. I realized it might be related to timing, regarding all those verbose messages take time, thus speeding down the USB-related processes.

Verbosity set to "verbose" shows:
D (2303) HUB: Root port reset
D (2303) HUB: Stage done: START
D (2303) HUB: Stage done: GET_SHORT_DEV_DESC
D (2303) HUB: Stage done: CHECK_SHORT_DEV_DESC
D (2363) HUB: Stage done: SECOND_RESET
D (2363) HUB: Stage done: SET_ADDR
D (2363) HUB: Stage done: CHECK_ADDR
D (2373) HUB: Stage done: SET_ADDR_RECOVERY
D (2373) HUB: Stage done: GET_FULL_DEV_DESC
D (2373) HUB: Stage done: CHECK_FULL_DEV_DESC
D (2373) HUB: Stage done: GET_SHORT_CONFIG_DESC
D (2383) HUB: Stage done: CHECK_SHORT_CONFIG_DESC
D (2383) HUB: Stage done: GET_FULL_CONFIG_DESC
D (2393) HUB: Stage done: CHECK_FULL_CONFIG_DESC
D (2393) HUB: Stage done: SET_CONFIG
D (2393) HUB: Stage done: CHECK_CONFIG
D (2403) HUB: Stage done: GET_SHORT_LANGID_TABLE
D (2403) HUB: Stage done: CHECK_SHORT_LANGID_TABLE
D (2413) HUB: Stage done: GET_FULL_LANGID_TABLE
D (2413) HUB: Stage done: CHECK_FULL_LANGID_TABLE
D (2423) HUB: Stage done: GET_SHORT_MANU_STR_DESC
D (2423) HUB: Stage done: CHECK_SHORT_MANU_STR_DESC
D (2433) HUB: Stage done: GET_FULL_MANU_STR_DESC
D (2433) HUB: Stage done: CHECK_FULL_MANU_STR_DESC
D (2443) HUB: Stage done: GET_SHORT_PROD_STR_DESC
D (2443) HUB: Stage done: CHECK_SHORT_PROD_STR_DESC
D (2443) HUB: Stage done: GET_FULL_PROD_STR_DESC
D (2453) HUB: Stage done: CHECK_FULL_PROD_STR_DESC
D (2453) HUB: Stage done: CLEANUP
D (2463) USBH: Processing actions 0x100
D (2463) USBH: New device 1
D (2463) hid-host: Found HID, bInterfaceNumber=0
D (2473) hid-host: Found HID, bInterfaceNumber=1

I could not find any parameter/structure field that could set some delay, timeout tolerance or whatever could make detection process more tolerant.

Any clue?

[ahsrabrifat]

Try different values (e.g., 5ms, 10ms, 20ms) and check whether it improves detection.

Code: Select all

vTaskDelay(pdMS_TO_TICKS(10)); // Adjust delay time as needed

[sraposo]

Hi, ahsrabrifat.

Delays of various values at several places were tried but all were ineffective.

[igi540]

Hi sraposo,
The fact that increasing the log verbosity to "verbose" fixes the issue suggests that the problem is related to timing. The USB host stack may be moving too quickly through the initialization steps, causing some devices to fail during the address assignment phase. Your log indicates that the failure happens during SET_ADDR → CHECK_ADDR. Some keyboards might require a longer reset recovery period before responding correctly.
Could you try to increase the root port delays in menuconfig?

Component config -> USB-OTG -> Root Hub configuration

Step 1. Increase only Reset recovery delay to 3000 ms. If that helps, you can decrease the value and find out which one works. If not:
Step 2. Increase Reset hold to 1000 ms. If not helps:
Step 3. Increase SetAddress() recovery time to 1000 ms.

[sraposo]

Hi, igi540.

Thanks a lot for your suggestion. I had already visited that Root Hub configuration page in menuconfig an I've thought of doing some experimentation soon, if needed.

The values you have proposed did not solved the problem, but they are sensible, considering the seemingly timing-related issue. Indeed, "Reset recovery delay" only made the error message take more time to be showed.

At that page in Menuconfig are mentioned the minimum values required according USB specification.

Guess what? When those standard values were input, problem has gone! It's nearly 100% the times the wired keyboard is detected and enumerated. Wireless keyboard keeps on working as well!

Debounce delay in ms: 100
Reset hold in ms: 10
Reset recovery delay in ms: 10
SetAddress() recovery time in ms: 2

In rare episodes, there were fails on detection of the wired keyboard. I'm not sure if they were related to the previous cause. I am a little suspicious of the USB female connector, although it never caused problem when connect wireless keyboard token.

I'll keep on watching how it goes. In a couple of days I'll return here to report the problem was really solved. Or I will come back soon if something wrong appears.

Thanks a lot to @igi540 and @ahsrabrifat for your cointribution.