STM32F207 USB Device Lib HS core w/ Emedded PHY USBD_GetDescriptor() FS descriptor bugfix

[barries]

Posted on June 18, 2014 at 16:24

After applying a number of bugfixes posted on the forum for the pre-Cube device libraries, I eventually found another one needed to get the HS core working in FS mode.

The issue is that, in file usbd_req.c, the USBD_GetDescriptor() function assumes that the internal core is HS only and only returns the FS descriptor if an external PHY is in FS mode. The symptom is that, when implementing a CDC emulated serial port, at least, the device will enumerate, appear as a serial port on the host, allow the host to open a serial connection and set and get the line (UART) settings, but will not allow serial data to be sent or received. Data sent IN to the host will disappear, seemingly without error (I didn't see any error handling code being called in ST's library, anyway) and attempts to write OUT from a Windows host will garner a ''serial write error'' (USB specific errors aren't exposed via virtual serial ports on Windows AFAICS).The fix I applied was to comment out the additional check for the external PHY as follows (I also moved the HS descriptor fetch into an else block). This enabled data to flow, though beware the numerous additional bugs! For performance's sake, you may wish to skip all high-speed related code when using the internal PHY.The Cube code seems to be better designed and hopefully has fewer of these issues.I suspect this particular issue escaped the lab because of ST not testing their code on an HS core with the embedded PHY, probably due to the fact that boards like their STM3220F-EVAL use an external PHY. I tripped over this porting code to IAR's STM32F207ZG-SK, which uses an embedded PHY.I really hope ST ups their game--providing high quality reference code would make their chips even more popular and less likely to be associated with ''oh, crap'' moments when a bug of theirs causes field reliability issues (I know, it's only example code, but the reality is that a lot of it gets fielded).Here's an example of how to fix the issue (feedback, related issues, suggestions welcome!).

  case USB_DESC_TYPE_CONFIGURATION:

&sharpifdef USB_OTG_HS_CORE      if((pdev->cfg.speed == USB_OTG_SPEED_FULL )

/*Bugfix: embedded ''HS'' PHY runs in FS mode &&

       (pdev->cfg.phy_itface  == USB_OTG_ULPI_PHY) */)    {      pbuf   = (uint8_t *)pdev->dev.class_cb->GetOtherConfigDescriptor(pdev->cfg.speed, &len);    }

    else

&sharpendif  

    {

      pbuf   = (uint8_t *)pdev->dev.class_cb->GetConfigDescriptor(pdev->cfg.speed, &len);    }Here's the top-of-file comment below for reference.

  * @file    usbd_req.c

  * @author  MCD Application Team  * @version V1.1.0  * @date    19-March-2012  #stm32f207zg-sk-hs-fs-phy-bugfix

[ADras]

Thank you for this information!

I have spent two days tracking down this exact same bug!

This is present in the most recent release (2.2.0) still!

After getting an idea that a USB error was thrown (and USB forced to suspend), I narrowed it down to this section of code and searched for it, and this post came up on the search results!

This really should be documented somewhere (or fixed and re-released)... or I just didn't notice it...

However, this is not CubeMX, and I do not intend moving in that direction yet... CubeMX adds another level of abstraction that I don't know what is going on...

While the example code might works fine as is if using the external PHY, I need to use the HS core in FS mode, as configured (in hardware) on the discovery PCB that I am using. This uses the internal PHY.

The STM32F429I-DISC1 discovery PCB would enumerate the USB-VCP correctly on my MacBook Pro, but not on a SmartPhone (Sharp SH-04H). I traced the bug down to this exact thing, applied the fix, and works perfectly now! How do bugs like this get through testing???

I am using the library STM32_USB-Host-Device_Lib_V2.2.0.

This can be found at the below URL.

https://www.st.com/ja/embedded-software/stsw-stm32046.html