STM32F7: Do not generate redundant IN tokens #11103
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
|
@desowin, thank you for your changes. |
|
@ARMmbed/team-st-mcd please review. |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
SeppoTakalo
approved these changes
Jul 25, 2019
0xc0170
approved these changes
Aug 9, 2019
|
ST_INTERNAL_REF 70627 |
This was referenced Jul 3, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
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:
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):
... the IN/NAK repeated multiple time until device was ready
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:
...
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.
Pull request type
Reviewers
Release Notes