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?

[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

[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 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

[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.

[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

[Rogers.Gary]

Well, first, thank you for a better reply, and in some ways, helpful. That this forum is visited by many people, and most not as skilled and experienced as you.

I was not a CubeMX user before, but I am becoming more swayed by it. I just finsihed three different design projects using three different ST processors, and during the design phase, the CubeMX tool was incredibly useful. There are some things I do not like, for example, the obfuscation layer it adds onto FreeRTOS. I prefer to put the regular implementation I am familiar with, problem is when code is regenrated, it takes the privilege of removing it from the project. Hope ST changes that. Clearly, you do not like Cube (seen your comments in other posts) and work at a much lower level and like to control to the bit twiddle layer. I do that, only when necessary.

When you say the USB interface is complex, maybe I agree. It can only be complex because of the USB device you are trying to access. The hardware connectivity from the processor to the USB-A socket really is not. I've implemented a few already, and on the first time using it, had a simple issue that had to be fixed with regards to VBUS sensing and enabling. But my hardware implementation was based on documents from ST and others I had found on the web.

So that leaves "complexity" in the device itself. And what makes one device different from the other then? Is there any documentation or knowledge base that can explain thse differences? Or are we users of such devices supposed to absorb it from the ether? The only way we can figure it out is to understand it. No information = no understanding. The USB libraries I used from ST in the past, they work. My hardware is the same. My USB device is the same. On this processor, using the CubeMX generated code, it does what I described. It can only come down to 2 things - the STM32L476 is different in silicon, or the generated code is different from before. If a device "breaks" in enumeration, is it the device, or the code used to access it?

Yes, I have now found the example code for a different board that I will try to transplant into my application. During my searches, I could not find any reference to that. If I had, this thread wouldn't be here until I found good reason to post.

Hopefully, when I do post again, you might find my question "better suited", not so far down the ladder and one you might respond to.

Regards.

Gary

[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.