STM32F407 + USB + ULPI Interface

[chradev]

Hi Giovanni,

I have 4.7 2014q2 (coming with ChibiStudio Preview 10) and as I see on https://launchpad.net/gcc-arm-embedded/4.7 it is the latest 4.7 version.

Code: Select all

ch> info
Kernel:       3.1.0
Compiler:     GCC 4.7.4 20140401 (release) [ARM/embedded-4_7-branch revision 209195]
Architecture: ARMv7E-M
Core Variant: Cortex-M4
Port Info:    Advanced kernel mode
Platform:     STM32F405 High Performance with DSP and FPU
Board:        STM32-H405 with USB3300
Build time:   Nov 20 2015 - 14:35:48

The test with it have the same problem.

Best regards
Chris

[chradev]

Hi to All,

Some new information about the problem both USB FS and HS with ULPI HS PHY (USB3300) to work simultaneously. While measuring the performance I found that both USB FS and HS cores really work simultaneously but for less than 10 sec. After that time USB FS stops communicating with USB Host while USB HS works as expected.

There is a difference if USB FS and HS devices are connected to Linux, Windows or Mac OS. While in Windows USB FS cannot communicate at all in Linux it can for a while. After stopping re-connection make it to start it again. My impression is that communication is freezing (or maybe suspending) and re-connection in Linux force it to restart.

You can see the results of performance measurement in the attached file. Unfortunately, the performance of USB HS is not as expected and it is comparable with USN FS one.

Does somebody have observation on or measurement of STM32F4xx USB HS with external ULPI HS PHY (USB3300) performance?

Best regards
Chris

[chradev]

Hi to All,

Some news about the problem both USB FS and HS with ULPI HS PHY (USB3300) to work simultaneously. While measuring the performance on a Linux box (a20-Lime2-SOM Linux 3.4.79+) new observations make it possible to gain an insights into it. To make measurement easy I prepared and use following Linux shell commands to control ChibiOS write command without terminal utility and visualization of the data received from the device:

Code: Select all

Start USB FS: echo -ne '\r\n\r\nwrite\r' > /dev/ttyACM0 | cat /dev/ttyACM0 > /dev/null &
Start USB HS: echo -ne '\r\n\r\nwrite\r' > /dev/ttyACM1 | cat /dev/ttyACM1 > /dev/null &
Stop  USB FS: echo -ne '\r' > /dev/ttyACM0 | killall -9 cat
Stop  USB HS: echo -ne '\r' > /dev/ttyACM1 | killall -9 cat

This way and and with combination with Linux utility screen /dev/ttyACM0/1 I found possibility to restore the stopped communication over USB FS. At one of the test sequences I get after a few restoration cycles to steady (working many hours without degradation or freezing) communication with USB FS. The result of described test sequence is shown on the graphics in the attached file.

My supposition is that the problem of communication freezing is some kind of incompatibility at interaction between terminating clients and ChibiOS application. This suggestion is strengthened by observation that very big amounts of data are buffered into the Linux box (causing long amount of data printed after sending a character to stop write command). Observed performance degradation and final freezing can be a result of buffer overflow in Linux at extremely fast data sending from the device. The behavior in Windows (tested always with terminal utility and data visualization) could be more critical causing the lack of communication at all.

Any ideas how to trace / debug the problem from the host and/or ChibiOS sides?

Best regards
Chris

[Giovanni]

On the ChibiOS side I cannot imagine what could cause a degradation, the system is static so there is nothing that can degrade over time.

Giovanni

[chradev]

Thanks Giovanni,

I know that and degradation and freezing are inside Linux / Windows boxes. On the other hand inability to communicate observed was at no data transfers at all. In my opinion there is something (maybe on CDC level) from ChibiOS side assisting it.

I have no big experience with USB communications but some mechanism has to limit data transfer speed at very fast data sending from the device to the host on a terminating client level. At lack of such a mechanism the client will loose data if it cannot proceed data too fast. For example it was observed that using Linux command screen throughput measured depends on baud rate set at command line.

Best regards
Chris

[Giovanni]

The only thing that I would check is the CDC messages exchanged on EP0. ChibiOS CDC implementation handles only a very small subset of the CDC commands, in case an unknown command is received the EP is stalled and the driver stops. It is up to the application to handle all the required messages.

The handled messages can be seen in serial_usb.c.

Giovanni

[chradev]

Thanks Giovanni,

This is good point and I will try to investigate it.

Second serious problem for me is the speed of USB HS with HS ULPI PHY (USB3300) which theoretical limit is 480 Mbps. I am expecting much bigger throughput over USB HS core. What is you suggestion about that problem?

Best regards
Chris

[Giovanni]

It is limited by queues (see the queues benchmark), you can get better results by not using queues but start transactions on linear buffers (this means not using serial_usb that depends on queues). Exchanging large linear buffers results in best performance.

Giovanni

[chradev]

You talk about the need to re-write CDC driver?

Chris

[Giovanni]

You can do a CDC device without using the current queued implementation, what matter are just the descriptors.

The current driver is done to be easy to use.

Giovanni