New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dcd_lpc_ip3511: isochronous support and endpoint accidental write fix #1676
Merged
Merged
Changes from 4 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
16f1554
lpc55s69 isochronous, dummy address for endpoint buffers to prevent a…
tswan-quasi 930c682
double cast of pointer to remove error
tswan-quasi 2c1ff26
(void) rhport for unused parameter
tswan-quasi 3f45f37
minor rename
hathach fe42785
dummy buffer only on EP0 OUT ZLPs
tswan-quasi 0b55047
typo fix
tswan-quasi 35e1a27
unused (void) cast
tswan-quasi e3b7ed9
use dummy for all ZLP for ip3511, fix lpc55 build with DEBUG=1
hathach File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really need to have this. Have you experience issue with dcd data is overwritten. USB data shouldn't be accepted when active bit is not set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is likely a better solution, but it was causing me some issues not assigning the offsets to another location. I am however using a different build setup than the one provided in the repo, I tried to follow the defines as they are in the family makefile, hopefully this does not cause any discrepancies.
In functions such as
dcd_init()
and others, the USB would write to the offset in_dcd.ep[...][...].buffer_xx.offset
and I think because the value of theDATABUFSTART
register was 0x2000000, the USB was overwriting some other values I had in SRAM. The reason I noticed it was because the LEDblink_interval_ms
inmain.c
was not changing correctly and it happened to be placed at 0x20000000 in my build. First place it happened was afterdcd_reg->DEVCMDSTAT |= ...
indcd_init()
A roundabout solution could be to always have the USB operate in USB_SRAM regardless of FS or HS, then in
edpt_reset()
andedpt_reset_all()
have the offset value be set based on the start of USB_SRAM (0x40100000) since setting to zero could potentially cause issues with the APB bus which start at 0x40000000 which is what the value ofDATABUFSTART
would be. I could see this potentially having other issues though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is not clear enough that USB overwrite the data, even if that is the case, I think we should properly fix it e.g explicitly set SKIP/DISABLE bit for endpoint first before zero it out. Otherwise we could run into issue that host may think we already received data (overwritten to zero), while it is ended up in dummy. Maybe we should do it in a separated PR.
PS: Do you have an easy/reliable way to reproduce this issue, I will try my luck to troubleshoot it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I noticed it on the video example when I was testing because
blink_interval_ms
was getting overwritten at address 0x20000000. I will take a look again as well as seeing if I can find proper solution.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A repeatable setup for me:
dummy
to beforeblink_interval_ms
is 0 (address 0x20000000) when it should be 1000There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I have narrowed it down to
dcd_edpt_xfer()
whenbuffer
isNULL
, occurring for EP0 OUT ZLPs. The code below makes it modifydummy
, and the other previous uses ofdummy
can be removed. From what I have seen, the USB writes 4 bytes of zeros to its offset location in this scenario. I am not sure if there is a proper solution to this aside from a dummy buffer?