Skip to content
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

Bugfix for COSDO Segmented Download #135

Open
AustinF93 opened this issue Feb 7, 2023 · 0 comments
Open

Bugfix for COSDO Segmented Download #135

AustinF93 opened this issue Feb 7, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@AustinF93
Copy link

Bug Details
Using a uint8_t for width in the COCSdo Download functions results in a premature end to the sdo transfer. On lines 337 and 388 where width = csdo->Tfer.Size - csdo->Tfer.Buf_Idx; is called, this results in width taking the lower 8 bits of the result. This can result in situations where the width is <7 even though there are remaining bytes. For example, if the size of the file is 1000 and the buffer index is at 231, the uint32_t subtraction yields 0x301 which is truncated to 0x01 through the uint8_t typecast enforced by setting this value to uint8_t width.

Solution I have determined
The fix for this is simply to change the width variable to a uint32_t. This allows the full amount of bytes to be transfered. The if (width >7u) check ensures that a max of 7 bytes are still copied into the frame.

See the attached co_csdo.c file containing the edits. For some reason it wouldn't let me upload a patch file so I changed it to a text file

0001-Fixed-co_csdo-Segmented-Download-bug.txt

Additional context
I have observed this fixing my code which is attempting to use this function to run a segmeneted download across a canopen network. With this fix, the segmented transfer works properly and without it, the transfer fails early. I verified through debugging that the exact moment at which the failure occurs is the situation detailed above \when the size of the file attempting to send is 1000 and the buffer index is at 231.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants