My virtual comport is not recognized by Device Manager.

MBang.1 · ‎2020-01-16

I need some help. I have a design that uses the STM32F407zgt. Up to now every thing has been going prefectly. I started my design using the STM32F407VGT or the Discovery board as my breadboard / proof of concept. With the 407VGT, I was able to create a virtual comport using CubeMX. I integrated the USB CDC library into my project and everything was great, the port got recognized and I could send and receive commands over the port. I then ported the code over to my new board (the 407ZGT) and the port no longer worked.

Now, on the new board the difference is there's a UPD720114 USB HUB between the micro and the outside world. When I power up my board, I can see the HUB recognized in Device Manager. I then start my debug application and I see activity on the port lights but then I get a "Device Descriptor Request Failed (Code 43)" message.

Now I know that the port works because I can download code to the board through the same USB port by putting the processor into BOOT mode and using the builtin bootloader and the STM DFUSe application.

I'm guessing the issue has something to do with one of the descriptors, but I have no idea what to look for. If someone could give me some ideas that would be greatly appreciated.

dbgarasiya · ‎2020-01-16

which os you are using?

waclawek.jan · ‎2020-01-17

Debug the Cube code as your own, it's open source. For starter, trace the progress of enumeration through the USB interrupt events. Particularly, find out if it gets to sending Device Descriptor at all. Compare to the functioning case on the Disco.

For debugging USB, I'd recommend you to get a bus analyzer, or a generic LA capable of USB protocol decoding. In this case, as it did not progress beyond Device Descriptor, it may quite well be that standard LA/oscilloscope, and "hand decoding" of the protocol would be sufficient. The hub is HS, but the link between hub and STM32 should be FS (unless you used the OTG_HS with a PHY and you did not tell us about it).

JW

MBang.1 · ‎2020-01-17

Win10

MBang.1 · ‎2020-01-17

Thanks for the response. I'm configure for FS and I'm trying to get hands on some test equipment.

I'm trying to follow the sequence through the IRQ handler. I receive a reset command and then I get an enumeration complete interrupt and it doesn't seem to go any farther than that. I'm assuming that the device descriptor is sent out after the first reset. If that's true what would be reasonable content for the Device Descriptor?

Mark

MBang.1 · ‎2020-01-17

A little more debugging shows, GetDescriptor() is never being called.

MBang.1 · ‎2020-01-17

I think I may have the answer. In the early parts of the enumeration process, the Host needs to determine the speed of the connecting device. In order for the Host to do this, the Host checks the state of the DM and DP signal lines. To be recognized as a FS device, which I am, the DP signal line must be pulled up to 5 volts through a resistor. I don't have this and this appears to be were I fail during the enumeration process.

I'll keep you posted.

Mark