STM32F2/F4 problems with various ULPI USB PHYs

[ian2399]

Posted on August 09, 2012 at 12:43

Hi

I have a problem with STM32F207/407 (not) working with a ULPI PHY, in this caseSMSC USB3340. The system (which is device-only) will work at USB full-speed but not high-speed. Itseems that others have similar problems - some ULPI-compliant PHYs seem to work,others not.

Logic analysis of the ULPI bus and USB line states show that during the USB_RESET period, the STM sets the PHY's Function Control register to generate the ChirpK indicating that the device can work at high-speed.  However, the ChirpK is never generated, so enumeration falls back to full-speed. Instead of sending the ChirpK, DP goes to 1.6V and DM to 0V.

It is possible that the problem arises because the USB Core sets theLPM bit (bit7) in the PHY's Function Control register. It looks at first sight as if PHYs which do notsupport LPM (and so ignore the bit) work correctly, and vice-versa.  For example on this forum we see a USB3343 not working and a USB3320 (similar but with no LPM support) working.

Does anyone at ST know if there is there a way to cause the STM32F deviceNOT to set the LPM bit in the ULPI PHY Function Control register? It would seem likely, but no such control is documented.

Does anyone have any further experience of which PHYs do and don't work in this regard?

Thanks

Ian

#usb-ulpi-phy-usb3340

[jvavra]

Posted on February 17, 2015 at 15:32

I can confirm that I have gotten the USB3300 working with the '205, '405 and '427. I can also confirm getting the USB3320 to work with the '205. As others have reported, I have NOT gotten the USB3340 to work with the '205 OR '427.

[swd]

Posted on October 08, 2015 at 10:01

Does anyone know if the USB3317 works ? The data sheet doesn't mention LPM.

Thanks

Simon

[Martin Devera]

Posted on January 25, 2017 at 02:07

I just ran into the same problem with USB3340 and F446. But interestingly when I set

bit 14 in DCFG it starts to work in HS !!

It is documented in F7 as:

Bit 14 XCVRDLY: Transceiver delay

Enables or disables delay in ULPI timing during device chirp.

0: Disable delay (use default timing)

1: Enable delay to default timing, necessary for some ULPI PHYs.

It is not in F446 docs however.... Anyone can test on another silicon ?

[Andrew Sterian]

Posted on March 26, 2017 at 08:16

Confirmed to also allow USB3343 to work in HS mode!

[Khouloud GARSI]

Hello,

Bit 14 was not documented in the previous version of STM32F446 reference manual. We have updated the document and the bit is now defined as a "Transceiver delay".

Below is a description of the bit in the reference manual:

Bit 14 XCVRDLY: Transceiver delay (Enables or disables delay in ULPI timing during device chirp)

0: Disable delay (use default timing)

1: Enable delay to default timing, necessary for some ULPI PHYs

For some external PHYs, a 1 clock cycle delay between the ULPI register write and transmit command is needed in order to ensure proper chirp execution. Otherwise, the device will not be enumerated as a HS one.

-> This delay is provided through setting bit 14.

Khouloud.

[eamonn2]

Hello,

Seconding Andrew's comment about setting the XCVRDLY bit helping the USB3343 work in HS mode. I'm using an F469.

[Mehran Memarnejad]

Hi,

Where did you add this delay in ST HAL or USB Middleware?

[James Murray]

I can confirm that setting that XCVRDLY bit allows the USB3340 to work with a STM32F746.

James

[Mehran Memarnejad]

Hi,

Where did you add this delay in ST HAL or USB Middleware?

[Martin Devera]

Hi, I added in in my usb init routine as I don't use HAL/Middleware. I use in-house simple USB framework.

However probably you can modify the register DCFG directly after calling HAL's USB init function.

M.