STM32F USB Device with USB3 host

Daniel Squires · ‎2014-03-12

Posted on March 12, 2014 at 17:40

Hi,

I'm developing both a driver on the host side and application on the client/device side using the onboard FS phy. Provided the host is USB2 both sides are behaving as expected. If I plug the device into a USB3 port on the same host PC things stop working.

The first bulk OUT write all goes well, the application at the device end sees the packet and handles the data. However with a subsequent bulk OUT write things go wrong. According to wire shark the packet was sent, and the device acknowledged. According the the device driver this was also the case. However no interrupt occurs at the device, the device application doesn't get any data. If the host sends a control packet it works as expected. If the device sends bulk IN packets these too work as expected.

Does anybody have any idea what night be happening? It seems as if some interrupt for bulk OUTs on the device is left disabled but I do not understand why the host side being USB3 would cause this to happen.

chen · ‎2014-03-12

Posted on March 12, 2014 at 17:48

Hi

Are you using USB Full Speed library or USB OTG library?

The OTG library will support USB3 ports (you need the very latest version).

I do not think the USB FS supports USB3 ports.

Daniel Squires · ‎2014-03-12

Posted on March 12, 2014 at 18:06

Hi,

I am using the OTG library.

I found a comment elsewhere whereby somebody resolved a similar sounding issue by updating but I am using the latest version I could find on ST site now and am still having the same problem. The changelog date is 19th March 2012, Version 2.1.0.

Thanks

Daniel Squires · ‎2014-03-12

Posted on March 12, 2014 at 18:21

Ok, so I think I have found some newer driver buried in amongst a 150Megabyte zip.

Come on ST, really? for a few k of text files I have to download 150Megabytes of bloatware?

Amel NASRI · ‎2014-03-13

Posted on March 13, 2014 at 09:23

Come on ST, really? for a few k of text files I have to download 150Megabytes of bloatware?

Are you speaking about the STM32CubeF4 package? This one contains all drivers for STM32F4 products with demonstrations, applications & examples on various STM32F4 hardware. So, it isn't limited to USB library.

Then, if there will be any new version, you will need just to update package, not to download it again.

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Daniel Squires · ‎2014-03-13

Posted on March 13, 2014 at 10:39

Yes I know, but all I wanted was the source code, not all the extra bloat. And looking at the supplied PDF it looks like we have to use this to get the latest code updates fro now on?

Please ST, provide the code on its own, preferably via an existing code management system, svn,git,mecurial. another bloated tool for every devleopment platform is a ridiculous situation.

Daniel Squires · ‎2014-03-13

Posted on March 13, 2014 at 12:43

Hi,

The whole Cube thing doesn't seem to relate to what I'm doing anyway. Whilst do have an STM32f4 Discovery running a port of the code and exhibiting the same issue, my target hardware is using the STM32F105 which the Cube package doesn't seem to support.

My code is based on what as far as I can tell is the latest release from ST for this device.

STSW-STM32046 / UM1021 V2.1.0

tsuneo · ‎2014-03-13

Posted on March 14, 2014 at 03:29

Sound like a problem of the host USB3.0 driver.

What is the host OS and its version?

Windows 8.0/8.1 have an in-box USB3.0 driver, but if the OS would be upgraded from Win7, the device driver of USB3.0 host controller may need to be updated manually. Before update of the driver, you may need to apply Windows update, because the driver update was distributed over Windows update.

For Windows 7/XP, which don’t have in-box USB3.0 driver, USB3.0 host is supported by manufacturers’ driver. Find the latest driver on the manufacturer’s site.

Edit:

Ah sorry, I didn’t read your first post well.

> However with a subsequent bulk OUT write things go wrong. According to wire shark the packet was sent, and the device acknowledged. According the the device driver this was also the case. However no interrupt occurs at the device, the device application doesn't get any data.

It suggests timing issue of the firmware around interrupt on the common OUT (RX) FIFO. Maybe, the second interrupt flag is cancelled by the process of the first one, when the second packet would arrive too early. I'll dig the source in this view point.

Tsuneo

Daniel Squires · ‎2014-03-14

Posted on March 14, 2014 at 10:58

Hi,

Thankyou for your interest.

I would just like to add that even with substantial amounts of time (seconds) between the 1st and 2nd bulk OUT the problem still occurs.

I am preparing a test case based as closely on one of the ST examples as possible to try and confirm that the problem still exists.

Daniel Squires · ‎2014-03-14

Posted on March 14, 2014 at 11:06

It occurs t me a similar problem to what you describe could maybe happening with the SOF int and the bulk OUT, as the IRQ is continuously triggered by this.