-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not working with PL2303 USB-serial adapter #13
Comments
I tried with two PL2303 cables, both made by VTOP, and see exactly the same problem on both. I'll get a few USB-RS232 adapters with other chipsets to see if the problem is chipset-specific vs. happening with all USB-serial adapters - serial programming cable combinations. On the other hand, I do not see such a problem with the USB programming cable from Digi, which apparently uses an FT232RL internally. |
You might need to make
Or maybe not. Even with reverting back to Edit: Oops, it wasn't even getting to the part where it sends |
I've now tried PL2303RA, PL2303GT and PL2303TA. Neither works (only checked with the tcdrain codepath). Intend to test with some non-Prolific chips (CH340G and FT231XS) later. Wonder if this is a hardware shortcoming vs. a Linux driver issue. |
The old usleep(15000) method works with PL2303GT and PL2303TA, but not PL2303RA. |
For more reliability, we may have to take a current time reading, send the serial data, and then have a timeout based on |
For now, I'm wondering if there is a bug in the PL2303 Linux driver, so I opened a ticket there: But even if that one gets fixed or we implement a workaround, there is still the checkum error with PL2303RA. |
We might want to add a verbose mode, or some sort of logging to aid in debugging. It'd be interesting to see ALL bytes that come back. I know that the RFU code flushes the receive buffer before it expects the target to send any data, and we might want to do that right before "Tell her we're done with initial loader." in It might be necessary to use a logic probe to monitor the TX/RX pins of the programming cable to see what actually goes out on the wire. There are some options for monitoring data sent to/from the tty, but that all happens before the Linux driver. |
Just to document this somewhere: All the PL2303 I tested had the same idProduct. But they had different bcdDevice: PL2303RA: 4.00 |
In 9fcddfe a --slow option has been implemented for the usleep()-fallback. |
When using a serial programming cable attached via an PL2303 USB-to-serial adapter, OpenRabbit fails:
By reverting the tcdrain() approach in rabbit_triplet() back to the old usleep() one, we get a bit further, but then fail at the pilot checksum:
The text was updated successfully, but these errors were encountered: