USB host HID LS chirp issue?

[JMarq.1]

Hi,

I have a USB host HID FS/LS on a nucleo board (also on definitive hardware this happens). It works with several keyboards (Logitech, Acer, china trades, ...).

Today, I connected an HP slim keyboard 803181-071 SP provided with my computer and after reset it doesn't initititate the enumeration. Using a logical analyser I see that both lines DP+ and DM- go high after connecting the usb host and there are 3 to 4 pulses around 50us. I suspect whether this could be a "chirp" sequencie trying to connect to the USB FS/LS host.

To fix it, I needed to add a short delay around 1~2ms inside the library function HAL_HCD_Connect_Callback(), to ignore those 3 or 4 short 50us pulses that take around 200us. Can this delay do any harm? Should this delay be already provided on the HAL USB library? To achieve this delay, HAL_Delay(2) can not be used because would be called inside the ISR HCD_Port_IRQHandler and will get blocked. I used a for to 20000 @ 120MHz to get 2ms.

I'm using CubeIDE 1.11.0 and last FW updates.

Could be a similar issue like in the following link:

https://community.st.com/s/question/0D50X00009XkZPYSA3/hid-host-bug

[waclawek.jan]

Which STM32?

.> I suspect whether this could be a "chirp" sequencie trying to connect to the USB FS/LS host.

What would that be, in terms of USB standards?

This sounds more to be a reset/charging artefact on the keyboard side. But that shouldn't really matter, as the host is supposed to wait at least 100ms (tATTDB, see Fig.7-29 in USB 2.0) after detecting attach before it asserts Reset. I know Cube is not famous for following meticulously the standard (e.g. https://community.st.com/s/question/0D50X00009XkZ4KSAV/usb-host , my post is at the 3rd "page" i.e. after two clicks on "More"), but even if I don't use it, I somehow don't want to believe this particular detail wouldn't be implemented properly.

JW

[JMarq.1]

This is a STM32F207ZG.

By "chirp" I was refering to USB HS negotiation, but I guess I was wrong. Keyboard should not try to negotiate HS since a reset has been issued.

The steps I detect are as follows:

1) STM32 host powers keyboard through VBUS

3) 70ms later, keyboard drives DP & DM high at the same time for a very short period of time of nanoseconds, returning both to low. I guess this shouldn't be that way, only DP or DM should go HIGH (in that case, DP per low speed devices such as keyboards).

4) DP stays LOW; whereas DM stays LOW for 30 us, goes HIGH for 46us, LOW for 56us, and finally HIGH. Attaching a low-speed device, DM should go HIGH and keep it HIGH till RESET is done.

5) The first pulse of just nanoseconds, seems to not affect and no interrupt is triggered.

6) The rising edge of the 46us pulse, triggers HAL_HCD_IRQHandler(), which triggers HCD_Port_IRQHandler(), which calls HAL_HCD_Connect_Callback(). The device is connected.

6) But at the falling edge of the 40us pulse, the HAL_HCD_IRQHandler() interrupt is triggered again, and __HAL_HCD_CLEAR_FLAG(hhcd, USB_OTG_GINTSTS_DISCINT) is executed, interpreting that the keyboard has been disconnected.

7) HAL_HCD_Connect_Callback() is called again 200us after the 56us pulse.

8) RESET is done

9) Bit PENA doesn't goes HIGH on the OTG_FS_HPRT register and the HAL library keeps waiting for this bit to go HIGH and the USB HAL state machine doesn't continue.

Attached images for these pulses on the DP line on a digital analyzer and oscilloscope. 

Executing a delay of 1~2ms on the first call of HAL_HCD_Connect_Callback(), the 46us and 56us pulse are filtered, __HAL_HCD_CLEAR_FLAG(hhcd, USB_OTG_GINTSTS_DISCINT) is not triggered, and the keyboard works. But I am afraid whether this delay is correct or can do any harm because of other interrupts not being executed meanwhile.

Thanks for your support.

[waclawek.jan]

Sorry for the late reply.

> Executing a delay of 1~2ms

After device attach is detected, host should wait at least 100ms, see USB2.0 7.1.7.3 Connect and Disconnect Signaling, TATTDB.

I guess the Cube software just went the easy way, violating standard, "mostly working". This is a common sight in the USB world.

JW

[JMarq.1]

Hi, no worries, many thanks for your answer. Using a for loop lasting 1~2ms works like a charm. Thanks