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.
On STM32H5 (with GPDMA), I saw some USB PD reception appearing to be empty, when packets were arriving quickly back-to-back.
When calling
receive
on the UCPD driver, you would usually provide a buffer big enough to cover the biggest standard packet type (e.g. 30 byte). The DMA will store data in the buffer, until its number of transfers are reached, even if this means handling multiple UCPD requests.It turns out that the DMA got two requests from the UCPD peripheral during one receive operation and advanced the memory pointer by itself. The UCPD driver did not stop the DMA after receiving a full message. Multiple messages ended up in the same buffer, concatenated.
This PR stops the DMA after receiving a packet, or a hard reset.
Tested with https://github.com/elagil/usbpd/tree/main/examples/embassy-nucleo-h563zi