Hi,
We are currently using a Qualcomm EVK and testing a flashing process through our remote setup using Virtual Here. The board is physically connected to a host machine, and the flashing process is executed from a remote Windows environment where the USB device is redirected through VirtualHere.
During the QDL flashing process, we are seeing intermittent failures that appear to be related to a USB communication interruption while QDL is transferring data blocks to the device.
In one of the failing attempts, QDL successfully detected the device in EDL mode and started the Sahara/Firehose communication. The log shows the device responding correctly at the beginning of the process:
HELLO version: 0x2 compatible: 0x1 max_len: 1024 mode: 0
READ64 image: 13 offset: 0x0 length: 0x40
READ64 image: 13 offset: 0x40 length: 0x3b8
READ64 image: 13 offset: 0x1000 length: 0x1000
...
However, after several 4096-byte block transfers, the process fails with the following error:
Error: qdl: failed to write 4096 bytes to sahara: No error
Error in Flash: Process exited with code 1
Based on the logs, the files are downloaded, verified, and extracted successfully before the failure occurs. The issue appears during the USB/EDL communication stage, specifically while QDL is writing data blocks through Sahara.
Since we are using VirtualHere, we would like to confirm whether this type of workflow is fully supported when the target device changes modes or resets during flashing. The QDL process includes stages where the device may reset or re-enumerate, and we suspect that the USB redirection session may be interrupted or may not reattach quickly enough for QDL to continue.
Could you please help us review this behavior and confirm if there are any recommended VirtualHere settings or best practices for this type of use case?
Regards,
Luis Flores
.
This sort of issue is almost always related to network latency.
"remote Windows environment where the USB device is redirected through VirtualHere."
Is over the internet? Are you trying to use a COM port to upload firmware to a board?
Yes, is it over internet and…
Yes, is it over internet and we are flashing the kit through a COM port.
.
Yes that is impossible without a low latency link. Your COM port chip is overflowing/underflowing due to the time taken to transmit data to/from the USB bus over the internet
Is there a way to fine tune…
Is there a way to fine tune that?
.
Yes implement your own flow control, either by software XON/XOFF or using RTS/CTS
Only send the next packet when you got the last transmitted successfully.
Okay, thanks!
Okay, thanks!