STM32F407 + USB + ULPI Interface

[chradev]

Thanks Giovanni,

I will look at this direction.

BTW, terminating utility used (Linux cat command) do not send any special CDC staff at all but degradation and freezing is a fact.

Best regards
Chris

[chradev]

Hi to All,

I would like to summaries the results of the tests done till now with latest (svn-8506-trunk) ChibiOS USB driver including ULPI support.
Application (attached) is running on Olimex STM32-H405 board with USB3300 module connected with short wires.
Config file .\btest-2\OLIMEX_STM32_H405_ULPI\cfg\board-ch405.chcfg can be used for reference and board files regeneration.
It can be migrated to other SM32F4 boards with HS ULPI PHY like WAVESHARE OPEN-407I with HS ULPI module.

Application itself starts 3 shells over USB FS, HS (with ULPY PHY) and USART1 while debug and test results are sent to USART2 (Tx only).
USB OTG FS and HS descriptors are almost the same except a few parameters required by FS and HS nature respectively
Demo shell command 'write' from ChibiOS is modified to measure communication throughput over the channel running it.

USARTs are connected to Windows 7 (i7 PC) via FTDI's FT4232-HUB (HS USB to 4x serial adapter with embedded USB HUB).
USB FS and HS are connected to either Linux (a20-Lime2-SOM Linux 3.4.79+) or Windows 7 (i7 PC) respectively.
Linux is connected via 1GB Ethernet and ssh (PuTTY and Eclipse/Terminal) is used to run write command from Win PC.
For measuring throughput write command was issued from Linux by the following methods:

Code: Select all

with data visualization:
  screen /dev/ttyACM0
  echo -ne '\r\n\r\nwrite\r' > /dev/ttyACM0 | cat /dev/ttyACM0
without data visualization:
  echo -ne '\r\n\r\nwrite\r' > /dev/ttyACM0 | cat /dev/ttyACM0 > /dev/null &
where ttyACM0 is representing USB FS device and should be changed to ttyACM1 for HS one.

For measuring throughput running write command from Windows PuTTY and Eclipse/Terminal utilities were used.

The results can be inspected and captured by PuTTY and its logging feature. Offline they can be processed in MS Excel.

Code: Select all

ChibiOS starting ... OK.
SDU2 Throughput [kBps] vs time [sec]:
           cur     max     min     avg
     5   585.8   585.8   585.8   585.8
    10   586.1   586.1   585.8   585.9
...
    40   586.2   586.2   585.8   586.1
...

Throughput over USART1 can be measured at different baud rates (115200 * n, where n=1,2,4,...) changing default value in halconf.h.
The measurement time (5 sec by default) can be changed in write_test function implementation (int mtime = 5;).

The measurement results show that throughput is limited by value of 584.7 and 586.4 kBps for USB FS and HS (with ULPI) respectively.
Measured average throughput value is slightly (1-2%) lower if data is visualized in Linux and a little more in Windows.

There are following problem found and not solved currently (with some related observations and thoughts included):
1. After connecting of terminal (observed only with 'screen' in Linux) utility to USB FS it stops communicating after a few seconds.

* behavior is repeated at re-connection without exceptions
* if the write command is issued in that period of a few seconds later communication is steady (for hours)
* if steady communication described above is stopped the shell stops communicating after a few seconds
* there is no successful connection in Windows with any terminal utility (maybe it takes more than a few seconds to connect)
* in contrast to USB HS ChibiOS prompt was printed always after connecting terminal utility to USB FS
* there is no currently acceptable suggestion about the source of the problem(s) and possible solutions

2. In other cases like in 1. (mostly tested without data visualization in Linux) after some time throughput is degraded down to 127 kBps

* throughput can be be restored from degradation with restarting of the terminated utility
* only once was observed a steady communication for hours after a few restoration cycles
* throughput degradation is probably result of host OS buffers overflow but definitely depends on ChibiOS part and the reason is unknown

3. Communication over USB HS with HS ULPI PHY (USB3300) never reach throughput more than 586.4 kBps

* throughput is limited theoretically by the baud rate of USB HS (480Mbps) but observed maximal value is 100 times lower
* inside ChibiOS it is limited by the performance of the queues used (according to Giovanni)
* migration to linear buffers can help (according to Giovanni) - not tested

In contrast to 1. and 2. connecting of any terminal utility in both Linux and Windows to USART1 and USB HS (with ULPI) always has a steady communication.
Observed small value of 584.7 kBps (2-3 times lower than 12Mbps) for USB FS can also be mainly limited by the queue usage.

Limitation of queue usage can be a problem in many cases at both USB FS and HS with ULPI PHY (and maybe at HS with internal FS PHY - not tested for now).
STM32F4xxx platform performance measured with 100 Mbps LAN is 75% lower than the theoretical throughput an it is normal to expect more from USB HS.

My long term target is to have cheaper and more efficient than 100 Mbps LAN solution based on Ethernet over USB with external HS ULPI PHY.
That is why I am working in parallel on a project based on ST STM32Cube SW with Host/Device USB FS/HS stack and FreeRTOS integrated.
There are similar problems in both projects so if somebody is interested and can help I can share this project together with detailed how-to.
I am also working on a hardware based on STM32F405RG and external USB3300 HS ULPI PHY with SDIO, FS/HS Host, Device and OTG connectors.

Any discussions, suggestions and/or help is welcome

Best regards
Chris

[Giovanni]

Hi,

I will give it a look during weekend, thanks for all the analysis.

Giovanni

[chradev]

Thanks Giovanni,

Maybe it will be helpful to share some of the results from my parallel test using STM32Cube SW.

Application is fully generated by STM32CubeMX from description file for the same HW (STM32F405RG & USB3300).
Generated staff consists of complete HW initialization and template main application with FreeRTOS integrated.

As a beginning I add a few features to re-direct standard input/output, newlib implementation and Makefile framework.
I have also added 2 FreeRTOS threads: LED blinker and USB Sender. One of the serial ports is used for debugging and test results printing.
In USB Sender thread I added USB FS and HS & ULPI initialization and a loop for sending of small packets via both USB cores with a second period.
The ST USB Device library is based on user defined data buffers, function to prepare and start data transfer and callback to continue till buffer end.
Really this is the use case you suggested to implement in ChibiOS. There is no performance tests implementation for now.

Code: Select all

char buffFS[512];
char buffHS[512];
uint8_t resFS = USBD_OK;
uint8_t resHS = USBD_OK;

void USBD_SenderTaskImpl(void const * argument)
{
   int i = 0;
   USBD_Interface_fops_FS.Init();
   USBD_Interface_fops_HS.Init();
   for(;;) {
      i++;
      sprintf(buffFS, "HiFS: %d\r", i);
      resFS = CDC_Transmit_FS((uint8_t *) buffFS, strlen(buffFS));
      sprintf(buffHS, "HiHS: %d\r", i);
      resHS = CDC_Transmit_HS((uint8_t *) buffHS, strlen(buffHS));

      buffFS[strlen(buffFS)-1] = 0;
      buffHS[strlen(buffHS)-1] = 0;
      printf("Sent (%d | %d): %s | %s\r", resFS, resHS, buffFS, buffHS);

      osDelay(1000);
   }
}

The first observation is that both USB FS and HS devices are enumerated as expected in Linux and Windows as a FS and HS devices respectively.
CDC ports (COMxx and /dev/ttyACMx) are added successfully. They can be terminated by any terminal utility and with 'cat' one in Linux.
The surprise was that communication with the port staying behind USB FS is stopping to communicate in a few seconds while HS - does it steady.

Fortunately or not USB FS / HS behavior is the same as one observed with ChibiOS tests and described as 1. in my previous post.
On addition the call to function CDC_Transmit_FS() to start new transaction return error saying the device is busy.
Reconnecting terminating utility print first one old message and then a few new one but omitting each second message.

My plans are to add performance test implementation to STM32Cube test as in the ChibiOS for throughput measurement while waiting your thoughts.

Best regards
Chris

[chradev]

Hi Giovanni,

There is some update.

Start adding performance test implementation to STM32Cube test I first prepare and send a buffer with 512 bytes size.
And surprisingly both USB FS and HS cores start working as expected at termination with 'cat' command under Linux.

Maybe in some reason sending a very small data chunks (the same as in ChbiOS shell at echoing of the command typed) has a problem.
This can explain the steady communication in ChibiOS via USB FS if write command is issued immediately after connection.

BTW, connecting to USB FS even without any data exchange always get to communication disappearing.

Best regards
Chris

[Giovanni]

Hi,

You should check for unhandled messages as I mentioned before. Using windows I don't experience problems, it is possible that your test setup sends some extra messages and the EP is stalled.

Giovanni

[chradev]

Hi Giovanni,

Screen command used in Linux is real terminal utility and send to CDC at least line communication parameters.
That is why I decided to use Linux 'echo' / 'cat' commands which are free of side effects and deal with data only.

Really 'echo' command in Linux only send the bytes in the string to the device as a standard file.
No extra messages are sent by 'cat' command in Linux as well. It threats any device as a standard file.
They simply open device as a standard file and send/receive data to/from device only looking for the end of file.

From ChibiOS side I use shell command write to send data to USB as in the most of the demos.
In STM32Cube application I use linear buffer filled with characters like in ChibiOS write command.

BTW, I try to enable debug in ChibiOS application but did not find it on a fast run.

Best regards
Chris

[chradev]

Hi to All,

You can take a look on my post about USB FS/HS performance measurement on:
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F4%20and%20USB%20FSHS%20with%20ULPI

Best regards
Chris

[chradev]

Hi to All,

I have finally solved some problems at measurement of the throughput via USB HS with HS ULPI and its verification from both device and host sides.
Unfortunately, these results cannot be achieved in ChibiOS without changes in current USB support.

Best regards
Chris

[Giovanni]

Hi,

Are you able to make a recommendation about those changes?

My current idea is to remove the queued mode.

Giovanni