USB overrides GPIO settings for DP/DM pins, in 'L452, too

[waclawek.jan]

It’s long known that in ‘F4, if the USB/OTG’s PHY is switched on, it overrides the GPIO settings of its DP/DM pins.

Today, I’ve spent some quality time debugging hardware, having been bitten by the same thing on a ‘L452.

I didn’t expect this, given entirely different USB module.

Neither of these is documented, of course.

Maybe it will spare somebody other’s time.

And maybe ST will document it, one day. It’s only^H^H^H^Hnot even 12 years since that first post, after all.

JW

[FBL]

Thank you, @waclawek.jan, for reporting this.

Indeed, the USB OTG HS peripheral can override PB14/PB15, even when those pins are configured with a GPIO alternate function. Disabling USB OTG HS, or explicitly clearing the transceiver power down bit, restores normal operation on these pins in their AF roles.

PWRDWN

Not sure for USB controller. Can you confirm the concerned bit is PDWN in USB_CNTR? I will try to reproduce. Then we can check internally whether this behavior can be documented in an FAQ or other documentation, and I will get back to you.

[waclawek.jan]

Hi ​@FBL ,

On the ‘L452, the USB stack was up and running, but hardware issue (which at the end of the day turned out to be faulty connector, with pins inaccessible for direct probing) prevented it to connect to host. To find out where’s the problem, I connected debugger, stopped execution, in debugger changed GPIOA_MODER bits for PA11 and PA12 from 0b10 for AF to 0b01 for Out, and then toggled manually bits 11 and 12 in GPIOA_ODR. As I couldn’t see any of the respective pins at host toggling, I attributed that foolishly to hardware fault (there’s also a MUX involved, sandwiched between boards thus inaccessible too, so fault of that might’ve been a possibility too). Only later it occurred to me that it might be the same issue as with the ‘F4 OTG, went to the USB peripheral in debugger and changed USB_CNTR from whatever state it was (don’t remember except the two LSBs being 0) to 0x0003. And then suddenly one of the pins started to toggle with GPIOA_ODR (the other was victim of the faulty connector, but after repairing I confirmed that one toggles as expected too).

This should be easy to reproduce on any ‘L452 board, maybe even just entering the DFU bootloader and then stopping in debugger, so no code needs to be written.

JW

 

[FBL]

Thank you ​@waclawek.jan 

 

Your observation is consistent with the pin sharing behavior on STM32L452: PA11/PA12 are shared with USB FS DP/DM, and when the USB peripheral/transceiver is active, those pins are controlled by the USB analog block rather than by GPIO.

 

In test, setting USB_CNTR.PDWN so that the USB transceiver enters power down disconnects the USB block from the pads, and GPIO control becomes visible again on PA11/PA12.

When PDWN ( or /PWRDWN in USB OTG controller) is set accordingly, the USB analog block is intentionally enabled on the shared DP/DM pins, so those pins are no longer driven purely by the GPIO logic. In other words, the USB peripheral has ownership on those pads while it is active.

This is why GPIO configuration changes on these pins may appear to be ignored until the USB transceiver is powered down or the USB peripheral is disabled.

 

Compared with OTG use cases, the behavior is often easier to misunderstand because OTG implementations can also involve additional signals such as ID in OTG cases and driving VBUS in host mode, which can make the pin ownership story less obvious. In the USB device only case, the expectation is simpler: when USB is enabled, the USB block controls the shared DP/DM pins.

So I agree this is worth documenting more explicitly in an FAQ.

[waclawek.jan]

> So I agree this is worth documenting more explicitly in an FAQ.

Looking forward to.

IMO, the pin and ball definitions table in RM should reflect these facts, too. A footnote, perhaps?

Also, is there a reason of having USB/OTG pins in the AF tables in RM?

JW

[FBL]

Hi ​@waclawek.jan 

I have forwarded your feedback to the dedicated team. IMO, an FAQ would be easier to maintain.

Q: Is there a reason USB/OTG pins appear in the AF tables in the reference manual?

Yes. USB DP/DM are not used as a normal GPIO alternate function signal; they are driven by a dedicated USB circuit. On some STM32 families, an AF setting may still be required for pin configuration, but the actual USB signaling remains controlled by the different USB hardware circuit

In practice, the exact pin configuration depends on the family, so the reference manual and datasheet should always be checked for the required settings and for which block owns the shared pins while USB is active. The software configuration remains device specific and functional.

[waclawek.jan]

Hi ​@FBL ,

Can you please forward to “dedicated team” my request to speak here for themselves? Thanks.

So they then can directly comment on my remarks:

> On some STM32 families, an AF setting may still be required for pin configuration

Which *some* STM32 families? Please specify in exhaustive detail in all USB-containint STM32’s DS/RM. Or, as @FBL suggested, a dedicated FAQ, preferrably in AN form.

>  so the reference manual and datasheet should always be checked for the required settings and for which block owns the shared pins while USB is active

But, the lack of this information is exactly what I’m complaining here about!

JW

 

[FBL]

Hi ​@waclawek.jan 

Check this FAQ: Why USB can take control of shared DP/DM pins on STM32 | Community

Your feedback is highly appreciated.

[Ali120]

Thanks for heads-up, JW. Classic STM32 PHY hardware behavior indeed.

 

Once the internal USB transceiver powers up (USB_CNTR.PDWN = 0 on Device peripheral, or OTG_GCCFG.PWRDWN on OTG), the analog line drivers hard-wire themselves directly to PA11/PA12. The GPIO AF mux matrix gets completely bypassed under the hood regardless of what standard registers report.

 

Only way back to clean GPIO control is explicitly dropping the transceiver into powerdown state first:

 

• USB Device IP (L452 / F0 / F1 / F3 / G4): Set USB_CNTR.PDWN

• USB OTG IP (F4 / F7 / H7): Set OTG_GCCFG.PWRDWN

Appreciate posting the confirmation for L4 always fun spending hours in the lab chasing what turns out to be un_errata'd silicon behavior.