Understanding USB at Low Level from Host

[Pavan_LohiaGroup]

I am Implementing RNDIS Over USB using the Stack provided by STM32 Team. The Data Received at the EP OUT Function is Correct for the First Few Bytes of Data, Post that the Data is Jumbled/Incorrect. Not Sure whats the Reasons though.

I tried Verifying the Differences with Different lrndis Stack, i.e. Using Bluepill (STM32F103) and lrndis. Using F103 and LRNDIS, Everything worked perfectly

I modified the Endpoint Address and it's Configuration too, (Device Descriptors, RNDIS Configuration etc) of STM32 Stack to that off lrndis. Still Same issue.

Thereby I tried to look at the lowest level possible, i.e. Sniffing the USB Ports via Wireshark using USBPcap.

I found that upto certain Packets they remain the same between controllers. Later Host Stopped Communicating with the L072. So.....

Here are my Primary Questions:

• As the Controllers and USB Peripheral(F103 Supports both FS and HS) Vary, Shouldn't I expect the same Packets being Shared among the Controllers thereby seeing same Low Level Data over Wire shark, (The End Points and Configuration remains the same with both)
• Can Someone Explain what exactly is that "Left Over Data". It could be a Part of the Actual Data also right?

• Should the Control response data also be same across the Controller?

• What Could be the Reason, When Using the STM32 Stack as is, Data Received upto a Certain Fixed Bytes are same post that it is way different. But the Size of Packet is same/correct as sent from Host.

[FBL]

Hi @Pavan_LohiaGroup 

1. F103 and L072 do not have the same USB. L072's USB embeds additionally BCD, LPM and more RAM for data transmission and reception (1KB instead of 512 bytes shared with CAN on F103). So, mismanagement of buffer RAM can lead to data corruption. Can you measure this fixed number of bytes received correctly? Then check max packet size defined in endpoint descriptor. 
2. I assume Leftover capture data are raw bytes that represent the data payload. When you capture USB traffic, each packet contains several fields, including headers and the actual data being transferred. So, it was not processed or expected by the USB stack. It could indeed be part of the actual data that was not correctly handled by the USB stack, leading to it being flagged as leftover. This can happen due to buffer mismanagement, incorrect endpoint configuration ...etc.
3. To conclude, this behavior could be linked to your buffer management and RAM allocation.