Posted on July 12, 2014 at 00:05 I am trying to get the USB in HS device mode working. I am using the ST USB OTG libraries in version 2.1.0. I modified the example code for a VCP device, so it fits my needs. Compiler flags are
USE_USB_OTG_HS
USE_EMBEDDED_PHY
USE_DEVICE_MODE
DMA is disable, and I tried to compile it with and without USB_OTG_HS_DEDICATED_EP1_ENABLED
However, every time I connect the USB cable, Windows states that the device is not recognized. I did a little bit of debugging of what happens when I connect the USB cable, and I am getting the following interrupts in the USBD_OTG_ISR_Handler, in sequential order:
DCD_SessionRequest_ISR
DCD_HandleUSBReset_ISR
DCD_HandleEnumDone_ISR
DCD_HandleUSBSuspend_ISR
DCD_HandleSof_ISR
12x DCD_HandleRsStatusQueueLevel_ISR
The last routine received the setup packages, but they are not handled. No interrupt for the DCD_HandleOutEP_ISR is ever generated. The interesting thing is that the same code used to work with the USB FS core (on a STM32F407 device), only when I switched to the HS core it failed.
Any idea what may go wrong?
Update 07/29/2014:
I got a USB package analyzer and found the following: After the setup package is received, the USB HS core is sending an acknowledge package. However, in this package the sync byte (00000001b) is corrupted. Only 6 of the 8 bits are sent (at least the package analyzer states that the first 2 bits were not received, ''__'' in the package data), so the USB HS core effectively only sends 000001b. Thus the acknowledge is rejected by the host, it sends the setup package again, and the enumeration never is completed. I compared this with the traffic using the FS core, and there the sync byte is correctly transmitted. I could not find any information in the documentation why the HS core behaves like this, not could I find a parameter related to the sync byte.
Any idea why the HS core corrupts the sync byte?
Update 07/30/2014:
I attached a USB connector including ESD protections and 22Ohms resistors to a STM32F4-Discovery board. It is also using an 8MHz HSE crystal as my own board. Without recompiling the code, I run it on the STM32F4-Discovery, and the USB HS works properly. No issues. So it is not the code which causes the issue. I then checked the clock signals, both HSE and PLL clock by outputting them on PC9. The signals of my board look identical to the ones from the STM32F4-Discovery, same frequency and shape of the clock signals. So a clock issue should be ruled out.
I am coming more and more to the conclusion that the USB HS on the STM32F405ZG does not work properly. Did someone else have such issues getting the USB HS working on this microcontroller? My last resort would be to rip off the STM32F405ZG from by board and solder in an STM32F407ZG, but I like to have at least a little bit of confidence that this will solve the issue.
