MKS22 USB CDC corruption?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MKS22 USB CDC corruption?

Jump to solution
1,094 Views
sjh1986
Contributor I

Hi,

I am using an MKS22FN256VFT to act as an adapter between CAN and USB CDC. 

After receiving CAN data, I send it as a 13 byte packet (4 bytes for message ID, 1 for length, and 8 for data) over the CDC device (taken from the mapsks22_1_dev_cdc_vcom_bm example). 

Most of the time this works great, however sometimes the received USB packet is gibberish. I am using a Saleae Logic Pro to view the CAN and USB data.
- When working, I can see in the USB data and in RealTerm that the 13 bytes are all correct. Looking at the USB traffic and the Data0/1 fields show the correct 13 bytes. 
- However, when the USB data is gibberish, I see the correct CAN data being received but the RealTerm and Data0/1 fields both show the same but incorrect data.  I even put a breakpoint inside "USB_DeviceKhciEndpointTransfer" looking for a correct length packet (13) with invalid data (one of the CAN bytes should always be the same), and this breakpoint is never hit. 

For me this means that the data is being sent through the layers of the USB stack, but still getting corrupted somewhere before being sent out.

Any ideas??

0 Kudos
Reply
1 Solution
1,089 Views
sjh1986
Contributor I

Mystery solved. I had originally meant to post the original message last night, but it say in my list of things to do...

 

The problem was that the data to be sent was being passed along as a pointer. The CAN data was being stored in an array of structs at file scope level, but copied to a function scope array before being sent through the USB stack. 

The USB stack didn't send the data straight away, and so the function scoped array memory location was no longer used to hold the data upon leaving the function. Setting the intermediate array as static solved the issue. 

View solution in original post

1 Reply
1,090 Views
sjh1986
Contributor I

Mystery solved. I had originally meant to post the original message last night, but it say in my list of things to do...

 

The problem was that the data to be sent was being passed along as a pointer. The CAN data was being stored in an array of structs at file scope level, but copied to a function scope array before being sent through the USB stack. 

The USB stack didn't send the data straight away, and so the function scoped array memory location was no longer used to hold the data upon leaving the function. Setting the intermediate array as static solved the issue.