Why the initial GET_REPORT in USB Host HID
Hi,
I am using my own board based on an STM32F207ZG with STM32F2 HAL v1.9.4. I implemented a USB HID Host using STM32CubeIDE (v1.19.0), simply enabling USB Host and HID Class support in CubeMX and generating the code.
I was able to read keys correctly from a standard USB desktop keyboard. However, I was not able to read from a USB HID RF reader.
While debugging the problem, I noticed the following code in `usbh_hid.c`, inside `USBH_HID_Process()`:
case HID_IDLE:
status = USBH_HID_GetReport(phost, 0x01U, 0U,
HID_Handle->pData,
(uint8_t)HID_Handle->length);
if (status == USBH_OK)
{
HID_Handle->state = HID_SYNC;
}
This initial `USBH_HID_GetReport()` therefore has to complete successfully before the state machine proceeds to `HID_SYNC` and eventually reaches `HID_GET_DATA`, where `USBH_InterruptReceiveData()` starts polling the HID interrupt IN endpoint EP1.
My question is: What is the intended purpose of this initial `GET_REPORT`? Is it required by the HID specification? or is it simply an initialization step chosen by the STM32 USB Host HID implementation?
In my case, the RF reader consistently responds with `NAK` to this initial `GET_REPORT`. Consequently, the STM32 HID state machine remains busy handling this control transfer and does not reach the normal interrupt IN polling state.
If I skip the initial `USBH_HID_GetReport()` and simply assign `status = USBH_OK;` in the `HID_IDLE` state, the state machine proceeds normally:
HID_IDLE --> HID_SYNC --> HID_GET_DATA --> USBH_InterruptReceiveData()
The RF reader then works correctly and the expected 8-byte input reports are received through the interrupt IN endpoint.
NOTE: As indicated on the HID 1.11 specs, I do understand that the RF reader may be expected to support `GET_REPORT`, and I am not necessarily arguing that the device is compliant by responding with `NAK` to this request.
However, returning to the code, I cannot see any subsequent use of the data returned by this initial `GET_REPORT`. Its apparent purpose in this state machine is simply to determine whether the state machine is allowed to proceed to the normal interrupt IN polling. So, if the initial report is not actually required by the application or used by the HID host driver, why make a successful `GET_REPORT` a prerequisite for entering the normal interrupt-IN polling state?
Even if `GET_REPORT` is expected to be supported by HID devices, making an otherwise unused request a prerequisite for starting normal input polling could potentially create interoperability problems with devices that do not handle this request as expected.
By chance, I also have another HID Host implementation running on another manufacturer MCU and firmware which works correctly for the same RF reader. I used a logical analyzer to capture USB traffic and Its initialization sequence does not contain this initial `GET_REPORT`; after the HID initialization it simply starts polling the interrupt IN endpoint.
To sum up, my questions would be:
1. What is the intended purpose of this initial `USBH_HID_GetReport()` in `USBH_HID_Process()`?
2. Is there any requirement in the USB HID specification for a host to issue an initial `GET_REPORT` before starting interrupt IN polling?
3. If the application does not need an initial input report, is there any reason why this request cannot simply be omitted?
4. Is the returned report data from this initial `GET_REPORT` actually used anywhere by the STM32 HID host implementation?
I have also found at least two previous ST Community posts reporting very similar problems involving `USBH_HID_GetReport()`, but I could not find a clear explanation of why this initial request is required:
In the first case, the author reports that `USBH_HID_GetReport()` never returns `USBH_OK` and that skipping its result solves the problem, but the reason for this behavior was not clarified.
The second case also reports that execution stops at the `USBH_HID_GetReport()` call in `usbh_hid.c`.
In the following link,
I would particularly appreciate clarification from ST or anyone familiar with the HID specification about whether this initial `GET_REPORT` is actually required, and what functionality the STM32 HID Host implementation is intended to obtain from it.
Thanks for your answers and sharing your experience.
