USB Toggling States between Enumerate and Idle

[Rogers.Gary]

I set up USB host in Cube MX. The STM32L476 hardware to the USB is connected the same as I have successfully used previously in an F4 processor. I am using pin PA8 to drive the power switch (STMPS2141STR)

Under "Connectivity", the mode is "Host Only". VBUS_Sensing is activated (although this did not seem to matter) The SOE and SOF boxes are not checked. Under "Middleware", USB_HOST set up for BSP "Drive VBUS_FS" is GPIO_Output, and I selected the PA8 pin "Found Solutions"

I then generated the code, and among other additions of code, it placed a call in main while(1) loop: MX_USB_HOST_Process(); Right after that, I placed a call: "HAL_Delay(1000)" so the output of a printf could be seen.

What is happening (or not): software does not appear to detect the connection when I plug in a USB stick. In the module "usbh_core.c" there is a function "USBH_Process(USBH_HandleTypeDef *phost)". Just before the switch statement, I placed a printf:

printf("state = %i\n", phost->gState);

I started with no stick plugged into the board, and at the fourth print of "state = 5", I plugged it in. The current draw on the power supply went up, so it did appear the USB was detected in hardware as the supply switched on. Here is the print out:

state = 0

state = 2

state = 5

state = 5

state = 5

state = 5 *At this point I plugged in the USB stick*

state = 5

state = 5

state = 3

state = 0

state = 3

state = 0

...and keeps doing this toggling

According to the enum for phost->gState, it toggles: HOST_IDLE, HOST_DEV_ATTACHED, HOST_ENUMERATION (6x), HOST_DEV_DISCONNECTED,HOST_IDLE,...

Also - why does it say the device was attached before it was plugged in? Then, after plugging it in, it goes to disconnect, then idle repeatedly between those states?

Since no examples are available anywhere, it makes it difficult to figure out what could be going on. Also, I am using a USB stick that does work on the previous F4 implementation.

[Rogers.Gary]

Hello...anyone from ST. Am I being blackballed in the community forums? Everyone's posts are getting answered, not mine. My question cannot be so dificult that no one can offer any help with it?

Please?

[WBOUG]

Hi @Rogers.Gary​ 

I will take your request in charge and I will find you a complaint that helps you to finalize your work

Just I need your ioc file to be able to test your work.

Best Regards,

Wael.

[Imen.D]

Hello @Rogers.Gary​ ,

Please share your ioc file, so it will be easier to help you on this issue.

Kind Regards,

Imen.

[waclawek.jan]

> Hello...anyone from ST. Am I being blackballed in the community forums? Everyone's posts are getting answered, not mine.

Please note that this is a primarily user-driven forum, with casual ST presence. Questions are answered usually by users who have answers on that particular topic; if there are none such then questions may remain unanswered. And, inevitably, questions, which can be blindly answered, are relatively simple ones, dealing with imple and straighforward interfaces and relatively simple or - which when answered, from outside may appear as magic - notoriously reoccurring questions, one might have needed to deal with and then may be willing to share the answer.

The fact that CubeMX churns out code (and more code comes with Cube) for complex interfaces such as ETH and USB makes users believe that using these interfaces is easy (can't quite blame ST, this is what the competition does, too). Well, if you are lucky, it is. But as these interfaces are still very complex and things may go wrong in many, many ways, some of them having complex and deep rooted cause. If you look through the forum, there are many questions of the "I clicked some USB in CubeMX and it does not work" character, some of them even attempting to do some shallow and usually just symptomatic search for cause; and the vast majority of them are factually unanswered. Simply because to answer these questions, you have to dig deep and truly own the code (and sometimes the associated hardware, too). And have to have a deep understanding of the topic, as USB is not living in isolation - it depends on the other party's behaviour, which, given the sloppy ways how USB is defined in some its portions, may and does vary widely and wildly.

USB MSC is one of the prime examples of this, especially if implemented on the host side, as USB itself defines only a thin intermediate layer (even there may things go wrong as the stick is not necessarily of the expected transparent-SCSI and bulk-only-transport type, I have come across such an and it was a relatively modern stick) and the bulk of real behaviour is left to SCSI, which brings in another set of sloppy definitions and uncertainties in the other party's behaviour. On top of that we have the issue of disks partitioning and file systems and...

So, while Imen jumped in to start some standard support process, the truth is, ST probably has no better crystal cube than any of the users here have and there's only a minimal chance to discover remotely where the problem in your case lies. So the best thing for you to do is return to the drawing desk... try several different sticks (and by several here I mean dozens and by different I mean as much differing in maker, capacity, production year as they can). Find out where the state machine goes wrong. Review power supply and ground paths. Use an USB bus analyzer (or a LA/scope capable of USB protocol decoding) to observe the communication. Stare at the code. Eat, drink and sleep regularly.

JW

[Rogers.Gary]

Hi jw,

If you read what I have written, it's pretty clear. I am using the SAME USB device I used in the F407VG, the SAME hardware connectivity and the same power switching arrangement.

I have also made clear what the code is doing. I have also downloaded documents for the CubeMX USB implementation.

My question still stands. Why is there no functioning example for the CubeMX generated USB mass storage? Has anyone at ST, or you, actually implemented a USB MS from CubeMX? If so, my questions on what I am seeing cannot be that foreign or unrecognizable?

So what I am asking for is some help,, not a deep rooted diatribe of perspectives of the many faces of how USB is implemented without offering a single line of help.

Gary

[waclawek.jan]

Hi Gary,

> Why is there no functioning example for the CubeMX generated USB mass storage?

How do you know there is none? I'd expect the examples from Cube would work on their respective boards. And, IMO, chances are that CubeMX generated examples would work on those boards (Nucleo, Disco, EVAL), too. Have you tried to run code generated from CubeMX on a Nucleo/Disco/EVAL, and found not working?

What in fact you are asking is, why the CubeMX generated code does not work on your hardware. And my answer - lengthy I admit - was, that there are many possible causes, and it's very unlikely anybody will give you a simple answer.

So, if you ask for a help in the form of a quick fix, I don't have it, sorry. But I tried to outline what you ought to do:

• review the power supply and ground paths - and by this I mean, review them from end to end, including connector connections and solder joints etc. Same for signals.
• observe the USB signals using a LA/scope, or, better, an USB analyzer (you may want to compare these with the working hardware)
• get several of those USB sticks to experiment with
• build an ownership of the code (that's the "stare" part)
• find out where the state machine goes wrong and why
• apply good debugging practices (that's where healthy living habits come in)

In particular, no, advancing the state machine beyond HOST_DEV_WAIT_FOR_ATTACHMENT without attaching a device is not normal and you should start there. Normally, this happens when the attached device pulls up one of the DM/DP lines (depending on whether it is a LS or FS device) against the internal pulldowns activated by the PHY set to host mode. So, assuming you've already double-checked for the continuity and hosrts, scope the DM/DP pins, check if they are both low after the OTG_FS is switched to host mode. If they are not, search for the reason - short to a neighbouring pin or line maybe?

Does this sound more like help?

I don't use Cube/CubeMX.

JW

[Bob S]

This is just a guess as I've never run the host side of the USB software, but the 1 second delay that you added in your main loop may be messing with timing that is required in the enumeration process. Try without the delay. And change your printf() that you put in the USB function to only print when the state changes. And presuming printf() goes to a UART, is your UART code polled or interrupt/DMA driven? Because polled UART TX will also add delays, though depending on your baud rate that printf output may be short enough to not matter.

[Rogers.Gary]

Hi Bob:

The printf does nothing to interfere with the process. It goes to the SWD interface which is extremely fast - at least 115kbaud. I have used it in interrupts and it functions without causing behavioral changes. How do I know? I can use a variable watch and see the same thing. I can take the delay out and it does the same thing. The USB code itself in the files has various delays to allow power supplies, etc to respond. So no, the delay or printf does not cause any change and the code does the same thing with or without it. As I mentioned, I am using the same USB device, implemented exactly the same way in hardware as I have done with a STM32F407VG.

Thanks for taking the time to try and help.

[WBOUG]

Hello

I promised you to send you the project you wanted and that's the case

You find in piece to join the functional USB poject.

Best Regards,

Wael

[Rogers.Gary]

Hello Wael:

I will check it over, appreciated. I re-posted my tech support case last night. I followed the example from the STM32L476VG processor, the same one I am using, that's used on the EVAL board. I also verified my hardware connectivity is the same, as the EVAL board. Initialization and calls are the same. Yet the detection of the device (tried several) does not occur (state remains at idle). I will try your example and see what happens.

Thanks again, will be in touch