Stream synchronization fixes #34
Conversation
Commit 56c5d37 ("Refactor cha_loop") changed libusb bulk transfer size from endpoint max packet size to 4096. This change inadvertently leads to RX stream desynchronization when there is large traffic on captured link. The data stream gets desynchronized because FTDI FT2232H prepends Modem Status and Line Status on every DATA packet it sends to capture host and the 4096 bytes buffer, when OpenVizsla is connected to High-Speed capture host, can hold up to 8 DATA packets and therefore the completed transfer can contain up to 16 status bytes, but transfer callback only skips the first two status bytes. Fix the issue by skipping the Modem Status and Line Status on every max packet size chunk within the received buffer.
In current bitstream introduced in commit d0192dc ("Update to latest FPGA bitstream") only 1027 bytes are captured when HF0_TRUNC flag is set. HF0_TRUNC can happen either when there is babble packet on the bus or when the gateware incoming ULPI buffer gets full. When HF0_TRUNC is set, the packet size stored in header is guaranteed to be larger than 1027 but only 1027 bytes are actually captured. The next packet data are then incorrectly treated as remainder of the packet and therefore the stream gets out of sync. Fix the issue by respecting gateware maximum captured packet size.
Truncated packets have HF0_TRUNC flag set and their size is greater than OV_MAX_PACKET_SIZE. Current gateware captures packets up to 1027 bytes long and therefore the truncated packet can only be observed when either there is a babble on the bus or there is capture buffer overflow (but not all capture overflows result in truncated packets because it all depends on the original traffic and what data was dropped).
Added a simple test case. This is really hard to come by in practice though because devices generally don't babble and the High-Speed endpoints with 1024 bytes wMaxPacketSize are pretty rare. Overflows don't generally cause truncated data because when overflow happens it can not only end up as "larger than real packet" but also as "shorter than real packet" because from perspective of input buffer there's no difference between dropping Start of Packet and End of Packet. Note that this doesn't completely eliminate all stream synchronization issues, but the remaining issue is in gateware. With the bitstream from OpenVizslaTNG/ov_ftdi#21 I am not able to get the stream to lose synchronization even under extreme loads ( |
Read cha data in max packet size chunks
Commit 56c5d37 ("Refactor cha_loop") changed libusb bulk transfer size from endpoint max packet size to 4096. This change inadvertently leads to RX stream desynchronization when there is large traffic on captured link. The data stream gets desynchronized because FTDI FT2232H prepends Modem Status and Line Status on every DATA packet it sends to capture host and the 4096 bytes buffer, when OpenVizsla is connected to High-Speed capture host, can hold up to 8 DATA packets and therefore the completed transfer can contain up to 16 status bytes, but transfer callback only skips the first two status bytes.
Fix the issue by skipping the Modem Status and Line Status on every max packet size chunk within the received buffer.
Do not lose synchronization on truncated packets
In current bitstream introduced in commit d0192dc ("Update to latest FPGA bitstream") only 1027 bytes are captured when HF0_TRUNC flag is set. HF0_TRUNC can happen either when there is babble packet on the bus or when the gateware incoming ULPI buffer gets full. When HF0_TRUNC is set, the packet size stored in header is guaranteed to be larger than 1027 but only 1027 bytes are actually captured. The next packet data are then incorrectly treated as remainder of the packet and therefore the stream gets out of sync.
Fix the issue by respecting gateware maximum captured packet size.