Cannot get STM32 host to enumerate a device

[magester1]

Posted on April 20, 2015 at 13:21

Hello everyone!

This is my first time in the forums... so greetings to all of you. I've been trying for the past week or two to compile the uC as a USB FS host and enumerate a device (for testing purposes I'm using a PC mouse), however, I haven't been able to do so till now. I'm using the STM32F4Discovery board and compiling with the gcc ARM toolchain. The demonstration that comes pre-compiled into the kit works flawlessly as a USB device. Ok, so onto the problem. First, I used the STMcube to generate the code for a FS Host with HID class and wrote the necessary missing 'user code' to drive the Vbus pin. After compiling and running the program, it reaches the enumeration state (ENUM_IDLE) waiting for a response (CMD_WAIT, and further down CTRL_SETUP_WAIT) and never leaves this point. When querying the URB status it returns USBH_URB_NOTREADY. I can see the mouse lit up so I know power is reaching it, I'm trying to discard as many 'dumb' problems as I can. Now, the provided host/device library doesn't really work for me, there are some things that don't work the way I need them to, so in time I was going to have to change it or re-write it. So, given that the generated code doesn't even seem to work I set on to that task. I've read the Reference Manual, and it's really a shame to see how little the initialization process and such are documented. It's as if they expected you to go look at the examples, which I don't really mind but it could at least be noted so in the manual. Anyway, I've gone through the process of setting up the needed registers with the appropriate values, even comparing against the generated code and the old USB_OTG/HOST/DEVICE library which, frustratingly enough, behave quite different during initialization and ISRs. And I seem to have reached the same blockage as with the STMcube code. The manual states that when you change the PHY clk speed after detecting a new device you need to perform a port reset (if the value actually changed) via the PRST bit in the HPRT register and this is consistent with the old library, however, the STMcube generated code doesn't follow this step. Is there a reason for it? Which of the two should I follow? After the host initialization routine (either performing the port reset or not) I set up channel 0 as a ctrl SETUP pipe. Then, I enable ch 0 and write two words to the TxFIFO (0x01000680, 0x00120000) which contain the standard get_descriptor request, right after that I enter an infinite loop. At this point 3 things can happen at random: 1) An HAINT interrupt triggers with HCINT(0) bits ACK and XFRC asserted. This is what *should* happen if the transaction was successful, right? 2) An HAINT interrupt triggers with HCINT(0) bit TXERR asserted. This indicates a 'Transaction Error', but it doesn't really tell you *what* caused the error... what should I do in this case? 3) Nothing... really, it just gets stuck in that loop because no interrupt is triggered whatsoever. Now, of course I could do something to avoid that, but how come no interrupt happens? Shouldn't I at least get a transaction failed or something? Something I tried over that is to resend the transaction in case a couple of seconds go by with no response (or a TXERR). Although I'm not entirely sure how to preform this... is there any specific order in which to retry a transaction? To start without much complication I decided to just restart the whole host, from disabling channel 0 and the host by setting PENA to 1 to flushing the FIFOs and performing a new port reset on the device. Basically, just calling the same host initialization routine again, however, after the channel is once again setup and enabled, writing to the TxFIFO does nothing, I go straight into case 3) above. Maybe I'm missing something and restarting the host is a more complex process, is this not how it's done? Should I just write into the FIFO those two words again and not worry about starting anew? I've been fighting with this for almost two weeks now and have really reached a point I can't seem to move anymore forward. I'd appreciate if someone could point me in the right direction. I can provide whatever other information is needed, I just felt that I shouldn't post my entire code or something like that right from the start, it's a bit long and might not even be necessary. Thanks! #stm32f4-usb-host #stm32f4-usb-host

[magester1]

Posted on April 24, 2015 at 02:54

Alright, I wanted to maybe provide some little more ''information''...

So far I haven't been able to compile some of the demo codes because of code size restriction, so I went ahead and downloaded the IAR 30-day evaluation IDE. I used STMcube to generate code for a USB HID device and a USB HID host. The first one seems to work fine, I can plug the kit to the computer and it will get picked up and enumerated (it shows up with lsusb). However, the seconds one still doesn't work... I download it and start it with the debugger, give it a couple of seconds and stop the execution, I can see it's still stuck inside the enumeration processes waiting. It'd be nice to try with something else that's known to work. Does any of you have a IAR project with a working USB host? I'd rather stay away from complex apps like DFU and such, maybe just connecting a mouse and have its movement lit up the Discovery's LEDs or something, that'd be really helpful. Is there any kind of extra configuration needed when using the STMcube to generate USB code? The device project seems to work though. I'm grasping at straws here, I really need to get this to work and I've already wasted three weeks with it. It's a shame though, I really like this kit and uC but if there's nothing I can do I will have to go look for alternatives. I'm probably missing something incredibly silly... or maybe there's just some problem with my board, is there any way to test that? I'd really appreciate it if someone could help me out. Thanks!

[TDK]

Posted on April 25, 2015 at 05:16

magester1, you may find some insight by looking at Tilen Majerle's libraries here:

http://stm32f4-discovery.com/2014/08/library-31-usb-hid-host-for-stm32f4xx-devices/It does not use the HAL libraries, so there are likely to be differences, but it may help to trace and compare what you're doing with what he did.The STM32CUBE stuff is relatively new and has not been adopted by everyone.  When I was looking for a toolpath to choose, I ended up using CooCox CoIDE (free) and the old Standard Peripheral library (v1.4) as it seems to be better supported and has more examples out there.  I then use the onboard ST-Link on the STM32F4DISCOVERY board as a programmer/debugger.  It's working out well.Good luck.

[magester1]

Posted on April 25, 2015 at 22:13

Hello there kistka.tim, thanks for answering!

I've dug around a little through that library, but it's nothing new, just a wrapper for the old STM firmware which also comes with USB host examples (DFU for instance) that don't work for me. That's the library I've been comparing with the STMcube generated code, which behave quite differently during the USB host initialization process. In any case, I downloaded the library and tried out the example in the website you linked to (with the mouse and keyboard) but I'm getting the same old problem. Right after starting the enumeration process and going into the XFER state (or some similar name) waiting for the control transfer, it just gets stuck in there and that's it. The thing about choosing a toolchain is not a problem actually, I have all that set up and running with arm-gcc and cmake... and it works flawlessly with the USART, GPIOs, pretty much everything except the USB host. But just to be sure I'm not messing up with that, right now I'm also using the IAR 30-day evaluation version. I'm thinking I may have to look a little deeper than the basic library... I don't know, maybe know what state all the OTG registers should be at right before starting a transfer and compare against that? To be honest I'm at a loss here, so I'll try anything that comes up =) Once again, thanks for your help!

[Tesla DeLorean]

Posted on April 25, 2015 at 22:36

Make sure the examples are configured for the DISCO board, most of then target the EVAL series boards with 25 MHz crystals. You need to make sure the PLL is set up for 8 MHz, and that HSE_VALUE defined in the project is also 80000000

I've posted VCP and MSC examples for the STM32F4-DISCO The STM32F4-DISCO also has a Firmware Upgrade example as part of the Standard Peripheral Library download, this uses an external Flash Drive to implement an IAP example.

[magester1]

Posted on April 25, 2015 at 23:18

Hey there clive1.

I'm using the following config: PLL: _M = 8, _N = 336, _P=2, _Q=7 with a SysClk of 168MHz and configured for HSE at 8000000. I've tried that one firmware upgrade example, compiled with IAR, and get stuck at the enumeration process as explained previously... Thanks!

[mike239955_stm1_stmicro]

Posted on May 28, 2015 at 03:59

Hi. I am trying to do the same thing, and I am experiencing the same thing. I don't have an answer yet, but I am looking. 

BTW: I am using the F407 Discovery board and the Keil IDE, but I don't think that has anything to do with it. This seems like a fundamental problem. I'm pretty sure the clock settings are right. I can get the VCP device-side example to work just fine. And for host-side, most devices other than a keyboard seem to work as well (and I've tried several keyboards). I don't have my test code set up to actually handle MSD or HUB, but when I connect them, it recognizes them and terminates properly, every time, with no TXERR.I am fairly new to USB but I've been dealing with embedded systems and low-level hardware drivers, including writing plenty of communications ISRs, on and off for over 25 years, so I am pretty sure there is something very wrong with this host-side driver. I'll post any developments here.

[jhgorse]

Posted on August 09, 2016 at 15:29

Mike,

Have you had any luck?Cheers,Joe