1 ACCEPTED SOLUTION
Accepted Solutions
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.
