Not working with PL2303 USB-serial adapter

[spth]

When using a serial programming cable attached via an PL2303 USB-to-serial adapter, OpenRabbit fails:

Error: Status line should be high after sending initial loader.

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:

loaded 5517 bytes from ../coldboot/pilot.bin
sending 5517 pilot
csumR 0xfd69 != csumU 0xd469

[spth]

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.

[tomlogic]

You might need to make tcdrain() a compile-time option. In my initial Windows test, processor verification errors out almost immediately.

reset rabbit
loaded 873 bytes from ../../../DCRABBIT_9.62/Bios/coldload.bin
flushing data for baudrate set
set baudrate to 2400
Warning: Processor verification sequence failed!
Error: Status line should be low before sending initial loader.

Or maybe not. Even with reverting back to usleep(15000) it failed. I'm guessing it's something with the serial ioctl code. I'll try to do a serial port capture later to see what's happening.

Edit: Oops, it wasn't even getting to the part where it sends coldload.bin. When I added some debug printf() calls, I found that it wasn't reading DSR (TIOCMGET never set TIOCM_DSR).

[spth]

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.

[spth]

The old usleep(15000) method works with PL2303GT and PL2303TA, but not PL2303RA.

[tomlogic]

For more reliability, we may have to take a current time reading, send the serial data, and then have a timeout based on start_time_ms + bytes_sent * ms_per_byte + timeout_ms. Wait for the STATUS line to change or for the current time to exceed the calculated timeout. In the calculation, timeout_ms would allow for some leeway and be at least 100ms, maybe longer.

[spth]

For now, I'm wondering if there is a bug in the PL2303 Linux driver, so I opened a ticket there:
https://bugzilla.kernel.org/show_bug.cgi?id=209359

But even if that one gets fixed or we implement a workaround, there is still the checkum error with PL2303RA.

[tomlogic]

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 rabbit.c.

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.

[spth]

Just to document this somewhere:

All the PL2303 I tested had the same idProduct. But they had different bcdDevice:

PL2303RA: 4.00
PL2303GT: 3.05
PL2303TA: 3.00

[spth]

In 9fcddfe a --slow option has been implemented for the usleep()-fallback.