R
robert_ps
Guest
We are in the business of developing embedded systems using microcontrollers. For compatibility purposes our devices interface with a computer using a virtual serial port over USB (2.0-FS). In the past month an issue surfaced with the USB communication between the microcontroller and Windows 10 (since the device generates more data). When a lot of data is transferred to the PC, some data is lost or other data gets inserted. The additional data can contain binary data and/or paths to files on the computer, we have also seen HTTP data appear in the terminal containing URLs that are opened in the web-browser. Since the embedded device does not have access to this information, this has to come from the Windows driver. The issue was seen on multiple computers with terminal applications (Putty/TeraTerm) as well as with our custom tools and scripts (written in C# and Python).
Using a logic analyser and a bare minimum version of the firmware that sends a counter in ASCII format, the problem was visualized. The low level communication happens as expected. Data is only sent when the PC requests it and all data gets acknowledged by the PC. All data fields contain at most 64 bytes and transfers that are multiples of 64 bytes are terminated with Zero Length Packets.
Data from the terminal was logged and analysed to determine where data is missing and at that point the following is visible on the logic analyser:
1) The PC requests an IN packet from the device
2) The device acknowledges the request and sends the data (<=64 bits)
3) The PC acknowledges the data (so the CRC is valid)
4) The PC stops requesting more packets for ~100ms but keep sending SOF every millisecond.
I tried the following to solve the problem in firmware:
Some side notes:
We use microcontrollers from two different manufacturers with different code bases and the issue persist with both of these devices. Slower PC's are affected more than faster ones and all pc's get a lot worse when "Maximum processor state" is set to 1% (under advanced power options on Windows) or dragging the terminal window around. Wireshark marks the missing package as "cancelled".
For us the workaround of 63 bytes per frame is sort of workable but far from ideal.
Since the problem is non-existent on Linux, we expect it to be some sort of interaction between the microcontroller drivers and the Windows driver. Any suggestions on what might cause the strange behaviour are welcome.
Continue reading...
Using a logic analyser and a bare minimum version of the firmware that sends a counter in ASCII format, the problem was visualized. The low level communication happens as expected. Data is only sent when the PC requests it and all data gets acknowledged by the PC. All data fields contain at most 64 bytes and transfers that are multiples of 64 bytes are terminated with Zero Length Packets.
Data from the terminal was logged and analysed to determine where data is missing and at that point the following is visible on the logic analyser:
1) The PC requests an IN packet from the device
2) The device acknowledges the request and sends the data (<=64 bits)
3) The PC acknowledges the data (so the CRC is valid)
4) The PC stops requesting more packets for ~100ms but keep sending SOF every millisecond.
I tried the following to solve the problem in firmware:
Limiting the number of bytes per packet to 63 (with multiple packets per frame)
The issue gets worse (random data from memory within seconds)
Limiting the number of bytes per transfer (various sizes, from 64 to 2048)
Gets better but the issue still persists. Less bytes per frame appears to be better
Limiting the number of bytes per frame to 63 bytes
Communication is reliable but throughput is very limited.
Some side notes:
We use microcontrollers from two different manufacturers with different code bases and the issue persist with both of these devices. Slower PC's are affected more than faster ones and all pc's get a lot worse when "Maximum processor state" is set to 1% (under advanced power options on Windows) or dragging the terminal window around. Wireshark marks the missing package as "cancelled".
For us the workaround of 63 bytes per frame is sort of workable but far from ideal.
Since the problem is non-existent on Linux, we expect it to be some sort of interaction between the microcontroller drivers and the Windows driver. Any suggestions on what might cause the strange behaviour are welcome.
Continue reading...