We use UART to communicate with our product.
We switched from FT232 to CH340 based cables a few years ago, and never had any problems before, until the last few months. We tried different vendors on ali, but they all had problematic cables (maybe it's the same under a different name, dunno

)
Anyway, updates failed and after inspection it was because the software received truncated frames from the device.
I finally managed to have a faulty cable here at the office.. they are dispersed around the world and they cost so little it's much cheaper to send a new one. Still, we got some back and they had completely different issues regarding voltage levels i attributed to the shitty USB spec and the VBUS variation (also the MCU is really picky with voltage levels i'm afraid. I wish i could just flip a bit to use TTL inputs)
A faulty cable will reset when attached to a device (windows's unplug-replug sounds) even though the power consumption is modest.
A faulty cable, at 115200bps will read up to 26-28 bytes before not accepting any more for some milliseconds.
I looked at FIFO, buffers, raising priorities, nothing on windows' side.
The scope showed solid voltage levels (other faulty cables would have a higher low level, or would have 3.3V high instead of the expected VBUS) but then it came to me: the interframe space.
Apparently if there isn't enough time after the stop bit, after enough bytes the CH340 will stop receiving.
Setting the UART on the MCU solves the receiving problem, but unfortunately the MCU doesn't let me set different TX and RX stop bits so i have to not use the UART FIFO and write byte -> wait some microseconds -> write again. the Bootloader doesn't report back much data so it's not that big of a problem, however it is a PAIN.
Did anybody ever encounter a simillar issue? Is there some driver magic i don't know about, instead?