Bugfix for COSDO Segmented Download

[AustinF93]

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.