MKS22 USB CDC corruption?

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

MKS22 USB CDC corruption?

跳至解决方案
1,134 次查看
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 项奖励
回复
1 解答
1,129 次查看
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. 

在原帖中查看解决方案

1 回复
1,130 次查看
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.