[STM32H7] USB otghs issues setting address - Page 1
Forum section: electronics / general

author: rounin
author_rank: Regular Contributor
timestamp: June 14, 2019, 08:46:32 pm
content: I'm trying to write my own minimal USB device stack for the STM32H750 (not because I want to, but because of some horrific bugs & lack of event callbacks in ST's CDC library), and am having some issues with initialization.I'm able to receive and respond to setup packets on the default control endpoint, and I happily send my device descriptor to the host. But when the host sends a SetAddress command and I set my address in the DCFG register, it seems like I don't receive any more setup packets after that, even though the host is trying to send them.Screen grab of usb protocol analyzer attached.Is there some other handshake I need to do with the otghs core to get it to use the new address? It seems fairly straightforwards. I'm able to read setup packets and send status responses just fine until the address changes...

author: ataradov
author_rank: Super Contributor
timestamp: June 14, 2019, 09:20:06 pm
content: Correct USB enumeration starts with host requesting the Device Descriptor (typically just the first 64 bytes).It looks like that's what is intended to happen in the frames with errors before the Set Address command, but something goes wrong there.

author: rounin
author_rank: Regular Contributor
timestamp: June 14, 2019, 09:46:17 pm
content: I do get a device descriptor request, which I respond to. Hmm. Screen grabs are kidna hard to show what is going on, here's another starting from first reset.For some reason, I'm getting some class specific requests before and after the device descriptor and set address messages. I think I'm not processing them correctly. Also not sure why they are there...A3 00 00 00 04 00 04 looks like a class request to "other", before the get device descriptor event. That is strange... It is there every time.I'm rewriting my driver ISR state machine right now. It was based off someone else's F4 usb driver and I don't think its really using the correct events.

author: ataradov
author_rank: Super Contributor
timestamp: June 14, 2019, 09:54:38 pm
content: I looked though some random logs I have saved over the years. Normally I see a series of JK chirps, then <Reset> and then <High-speed>. In your case you have "<Reset> / <Target Disconnected>".It appear that your device does not handle the switch to HS mode correctly, so pay closer attention to that part.Also, it looks like you have SOFs disabled. Enable them for low level debugging, it makes it much easier to align things.

author: rounin
author_rank: Regular Contributor
timestamp: June 14, 2019, 10:06:47 pm
content: Hmm. Thanks for the tips. I'll take a look at the initialization too, sounds like maybe the host thinks I'm starting to init in full speed mode and then I'm mangling the switch to high speed. There are some PHY delay settings and mode settings I'll double check.

author: rounin
author_rank: Regular Contributor
timestamp: June 16, 2019, 09:59:47 pm
content: Getting a little closer, it was that I was changing things before the otghs controller was ready. I was trying to change things on the "data in fifo" interrupt and immediately handling the setup packet, but it looks like the core really wants me to wait for a "setup phase done" interrupt before I do any processing of the setup packet.Still not working, (need to move more code around) but I can receive more packets after setting my address and the host is accepting my device descriptor! The host is moving on to asking for config descriptors. This is looking more promising, yay for new errors!Still not sure why initialization is giving the reset. Hopefully a PHY setting....

author: rounin
author_rank: Regular Contributor
timestamp: June 16, 2019, 11:07:20 pm
content: Hey I show up in lsusb now. This is a lot more fun than last week ^.^