Commit Graph

9 Commits (75c823c1a35fcb5bf5501e76c10014f45d1a9515)

Author SHA1 Message Date
Ireneusz Gaicki b9c4076741 STM32F7: Do not generate redundant IN tokens
When STM32F746-DISCO board was being used in (unsupported) USBHost mode,
the communication was unreliable. Our investigation revealed that the
problem lied in redundant IN tokens that the host generated even though
it shouldn't. This could lead to endless high-frequency NAKs being
received from device, which caused watchdog reset as USBHost spent all
time in interrupt handlers.

In our application the clocks frequencies are:
  * HCLK = 48 MHz
  * APB1 = 6 MHz
  * APB2 = 12 MHz

We have captured the raw USB High-Speed traffic using OpenVizsla.
Without this change, when USB MSD device connected to the system
responded to IN with NAK, there were excessive IN tokens generated about
667 ns after the NAK. With this commit the IN tokens are generated no
sooner than 10 us after the NAK.

The high frequency of the IN/NAK pairs is not the biggest problem.
The biggest problem is that the USB Host did continue to send the IN token
after DATA and ACK packets were received from device - *without* any request
from upper layer (USB MSD).

The USB MSD devices won't have extra data available on Bulk IN endpoint
after the expected data was received by Host. In such case IN/NAK cycle
time is only houndreds of nanoseconds, the MCU has no time for anything else.

The problem manifested not only on Bulk endpoints, but also during
Control transfers. Example correct scenario (when this fix is applied):
  * SETUP stage
    * SETUP [host -> address 0 endpoint 0]
    * DATA0 [80 06 00 01 00 00 08 00] [CRC16: EB 94]
    * ACK
  * DATA stage
    * IN
    * NAK
    ... the IN/NAK repeated multiple time until device was ready
    * IN
    * DATA1 [12 01 10 02 00 00 00 40] [CRC16: 55 41]
    * ACK
  * STATUS stage
    * OUT
    * DATA1 ZLP
    * ACK

Without this commit, in DATA stage, after the ACK was received, the host
did send extra IN to which device responded with STALL. On bus it was:
  * DATA stage
    ...
    * IN
    * DATA1 [12 01 10 02 00 00 00 40] [CRC16: 55 41]
    * IN
    * STALL
    * IN
    * STALL
  * STATUS stage
    * OUT
    * DATA1 ZLP
    * STALL

In the fault case the next SETUP was sent only after 510 ms, which
indicates timeout in upper layer.

With this commit the next SETUP is sent 120 us after the STATUS stage ACK.
2019-07-24 11:40:49 +02:00
jeromecoutant 7d05f22b31 STM32F7 warning compilation
[-Wparentheses-equality]
[-Wsign-compare]
2019-06-07 18:10:03 +02:00
bcostm 58c4a5f83e F7 ST CUBE V1.10.0
F7 HAL driver V1.2.5
2018-02-12 10:37:03 +01:00
adustm 8058e04238 F7 ST CUBE V1.7.0 2017-06-23 09:49:31 +02:00
Michel Jaouen c581230cd3 USBHOST: TARGET_STM fix in hal for hub support 2017-05-09 16:18:33 +02:00
jeromecoutant b77533dd51 STM32Cube_FW_F7_V1.6.0
CMSIS v1.1.2 => v1.2.0
    STM32F7 HAL v1.1.2 => v1.2.0
2017-03-06 16:48:23 +01:00
jeromecoutant f5b62208f4 STM32Cube_FW_F7_V1.5.1
CMSIS v1.1.0 => v1.1.2
    STM32F7 HAL v1.1.0 => v1.1.2
2017-01-13 13:29:45 +01:00
Michel Jaouen 8af69dcbd6 STM32 HAL HCD : USBHOST changes for f4,f2,l4,f7
- reset toggle_out , toggle_in at init
-  in/out toggle in on ctrl endpoint
- remove call back when transmission restarted
2017-01-02 09:48:15 +01:00
Christopher Haster 26ced98734 restructure - Restructured cmsis directory
targets/cmsis -> cmsis
targets/cmsis/TARGET_* -> targets/TARGET_*/device
targets/cmsis/TARGET_*/mbed_rtx.h -> targets/TARGET_*/mbed_rtx.h
2016-10-04 17:51:44 -05:00