Trying to get USB device working

[temp2010]

I'm trying to get my STM32 custom board to show up as a USB device on my Windows 10 computer. I realize there are MANY moving parts. It's not working yet. I appreciate your help!

I'm using STM32F105R8T6 with pins 44/45 (PA11/PA12 aka OTG_FS_DM/OTG_FS_DP) connected to usb hub's DM/DP respectively.

Note that pin 43 (PA10 aka USART1_RX aka OTG_FS_ID) is wired on the pcb to be used for USART1, not USB OTG ID. I'm intending for a full time USB device, not with OTG hosting, so this pin wasn't connected for that purpose during pcb design.

I downloaded STM32Cube_FW_F1_V1.8.0 and found inside it .\Projects\STM3210C_EVAL\Applications\USB_Device\CDC_Standalone. I copied that folder and got the project to build using Atollic TrueSTUDIO for STM32, version 9.3.0. I then edited a local copy of stm3210c_eval.h in order to use my desired USART1 rather than USART2, use different LED positions for my custom board, and couldn't specifically find any USB configuration in that .h file. (Note suspicious thing: This example app was NOT using USART1 that possibly conflicts with OTG_FS_ID.)

I programmed my MCU by going into debug mode through my ST-LINK. I have found that after doing this once, subsequent power cycles still have the program. I've both assumed that as well as re-ran in debug mode.

I'm running USBView from FTDI, which shows so much USB detail. I can see my two-input USB hub. I can see a USB flash drive plugged into the hub's second port. But the USB hub's first port is described by USBView as "NoDeviceConnected".

QUESTIONS:

1) I've tried stepping down into the USB code, and I have decades of experience stepping into unknown microcontroller code, but I don't see any recognizable status. Is there something I can look for to see if this process was successful?

2) I'm wondering about that OTG_FS_ID pin that I'm using for other purposes. Is there a way to look with debug to see if the MCU is attempting to get into host or device mode? Is this pin required? (Note that I've alternatively jumpered this pin to GND or 3.3V, and I my hub still doesn't show anything connected in USBView. So I may have eliminated this as an issue.)

3) Be aware that this hub is on my custom PCB. The second port is proven to work, and I see all through points (host side, device side, device side) in USBView. Nevertheless, there could be an error on my PCB with regard to configuring this hub for the full time presence of the MCU. (Or is it not full time due to misc timing and debug reboots?) Because of this additional ambiguity, I'd really like to be able to see the STATUS of the USB DEVICE port in my STM32.

Thanks very much

[waclawek.jan]

The Synopsys OTG IP used in the STM32 is a very complex and rather quirky machine. And documentation is poor.

As a preliminary, you have to make sure that you have at least 14.2MHz system clock up and running, your 48MHz clock is up and running, and any relevant clocks are enabled in the enable registers of RCC. You also make sure the PHY is enabled by setting OTG_FS_GCCFG.PWRDWN (very confusing name).

First you probably want to avoid dealing with the OTG machine i.e. role switching (of which the ID pin is part), as you seem to seek to use only the device mode - that's easy, set OTG_FS_GUSBCFG.FDMOD and you're done. OTG_FS_GINTSTS.CMOD indicates the current mode.

Then your device ought to pull up DP to indicate to host (hub) that it's there. This depends on PA9=VBUS - the idea is, that you are not supposed to pull up DP until you're sure there's a host who listens there (rationale is, that a connected but unpowered host could be damaged by the current from the pullup). Newer STM32 have a bit to override this behaviour, but it's not there on the 'F105 so you have to set GCCFG.VBUSBSEN and make sure that DCTL.SDIS = 0 (not soft-disconnect), then if voltage rises on PA9-VBUS, you can see  GOTGCTL.BSVLD getting set, and the internal pullup being connected on to DP.

If at this point you are indeed connected to host, it should respond by asserting a reset state, which you'll observe as GINTSTS.USBRST being set.

From there things get ticking rapidly, as host will start the enumeration process by sending SETUP packets and expecting timely response. For that you need to already have FIFOs set up, endpoints enabled, handlers in place, etc.

Generally, if the machine is not very seriously broken for some reason, you should be able to observe all the action by instrumenting the USB interrupt, as except the initialization, everything after that happens through that interrupt.

I don't Cube.

JW

[temp2010]

JW,

Thanks very much for the thorough answer. I see a couple things within my ability to address. A question: I tried to copy a legacy circuit that used an STM32F042C6T6. The only connections it had were USB_DM and USB_DP (PA11, PA12). It did NOT have an ID connection and also did not have a VBUS connection. Now that I'm using the STM32F105R8T6, is it indeed the fact that I *must* have the PA9=VBUS connection? PLEASE CONFIRM. Right now, that's USART1_TX. Well, USART1 is optional, so I may need to jumper both RX and TX for ID and VBUS.

I didn't look before because I thought I was safe copying the legacy circuit. Do you know if there's a good app note on using this USB engine?

I take note of measuring the DP pin. I take note of observing GINTSTS.USBRST. I don't yet know how to observe GINTSTS.USBRST, but I'll read up and hopefully figure it out. I have been doing multiple MCU's for 39 years.

Finally, if I can't get things working soon, are you personally available for hire to get me past this point?

BTW, I see that you don't Cube. I had hoped that all those things you mentioned were already taken care of in the example application.

Thanks very much

[waclawek.jan]

The 'F042 has a different USB module, a device-only. Much simpler. You'd find it in the 'F103 - maybe you want to migrate. Or you might want to migrate to 'F20x/'F40x.

> Do you know if there's a good app note on using this USB engine?

AFAIK, there's none.

> I don't yet know how to observe GINTSTS.USBRST

Instrument the USB ISR - output GINTSTS content to some UART, or some other serial you can observe using oscilloscope/LA, or similar. Up to that point, you could also simply use breakpoint in debugger and observe the registers' content there, but after that, when data actually start to churn in and out, it's too quick and the host would time out.

> are you personally available for hire to get me past this point?

No, sorry, no time. And I also guess I'm at the other end of the world (Central Europe) which would make things extremely impractical. I'm also quite sure you'll cope. And at this point I already hate the given module a bit too much... :)

> I had hoped that all those things you mentioned were already taken care of in the example application.

They might've been. Folks are apparently able to get it going just by clicking. In this particular case, having PA9 connected appears to be a must - I don't have personal experience with 'F105 nor 'F1 as such (they are rather old and have the quirks of the prototype) though.

JW

[temp2010]

Thanks, JW. I sincerely appreciate your help.

Hey, I'll be in Stuttgart in April... But I need to get this working before then.

I jumpered PA9=VUSB over to 3.3V. Now, rather than "NoDeviceConnected" I get "DeviceFailedEnumeration" and all the Device Descriptor stuff in USBView is 0x0000. So the PA9=VUSB=3.3V got me further down the road.

Now, I read in the datasheet "The USART peripheral operates with the internal 8 MHz oscillator (HSI), however the CAN and USB OTG FS can only function if an external 8 MHz, 14.7456 MHz or 25 MHz clock (HSE) is present." Well, oops, I copied a 16MHz crystal from the legacy circuit. That might be what I need to change next. The wrong USB data rate could explain failure to communicate any data. I just ordered both 8MHz and 25MHz crystals to try.

(Datasheet: https://www.st.com/content/ccc/resource/technical/document/datasheet/e4/f3/1a/89/5a/02/46/ae/CD00220364.pdf/files/CD00220364.pdf/jcr:content/translations/en.CD00220364.pdf)

[waclawek.jan]

That's only for the bootloader to be able to work with USB. As the bootloader does not know what frequency crystal you use, it has to "guess" comparing it to HSI, and then select one from a predetermined set.

The 16MHz is probably OK, if you can generate the required 48MHz out of it in RCC. If you want to check it, the Cube code is quite a mess, so it's probably easier and certainly better to read out the RCC registers and check against the RM.

JW

[temp2010]

Thanks. Tomorrow morning, I'll go try to find doc on where the RCC registers are (as well as that GINTSTS you mentioned earlier). Perhaps you already know doc pointing that out. (I just checked, and the chip datasheet neither defines RCC nor points to doc.)

[temp2010]

JW,

It took a while to find it right in front of my eyes, but I just reconfigured PLL mult/div to account for 16MHz xtal instead of 25MHz xtal.

Now USBView shows "DeviceConnected: STMicroelectroncis Virtual COM Port".

SUCCESS! Thanks for your help.

On next to actually bidirectionally communicating between my Win10 host and STM32.

(((Detail/Background: I have lots of PLL and MCU experience, but the cube code is written very obtusely with many macros. But once I realized the necessary config was right there in front of me in main.c, I was able to figure out the macro meanings and adjust them.)))

[temp2010]

JW,

FYI a few days ago I got bidirectional communication working between TeraTerm (serial) on Windows 10 and my STM32 MCU. In summary, the issues were proper PLL configuration using the existing 16MHz crystal, plus jumpering and pulling PA9=VUSB up to 3.3V.

Thanks for your help.