I am reusing the Bus Pirate OpenOCD protocol for another project, see here for more information:
If OpenOCD crashes (or gets killed with Ctrl+C) and leaves unread data for the current JTAG command on the USB CDC virtual serial port interface (for example /dev/ttyACM0), the data apparently remains in some operating system buffer.
The next time OpenOCD connects to the Bus Pirate on the same serial port, this stale data is then read back and you get error message "Buspirate did not answer correctly!" or "Buspirate error. Is binary/OpenOCD support enabled?" on start-up.
Therefore, I think routine buspirate_jtag_enable() in OpenOCD should read and discard any stale data upon connection. After all, the Bus Pirate protocols (both text console and binary mode) are from the master/slave type, so the slave should not have anything to say until the master has issued the first command.
I have actually tested this with my Bus Pirate clone, see routine UsbConnectionLost() here:
https://github.com/rdiez/JtagDue/blob/m ... ection.cpp (https://github.com/rdiez/JtagDue/blob/master/Project/JtagFirmware/UsbConnection.cpp)
There are actually few things that can happen:
BP was sending data as reply to some command, and the command finished.
BP was in the middle of tap_shift function, and still is there.
For the first flushing would suffice.
For the second case, there almost no real solution. You need to finish the sending of the tap data to end this function. (up to 2kb of data that needs to be sent). There is no side channel on which you can signal BP to restart (its a serial port). Using RTS/DTR could work, but not universal for all states in which BP can be. (user could have BP that is in transparent bridge mode, RTS DTR are ignored or else). For BPv4 it would be possible to send some "control usb packet" to reset buspirate, this would also need fw support. (and would no be compatible with BPv3)
> For the second case, there almost no real solution.
I know the current Bus Pirate firmware is optimised for speed and code size, so a good solution is probably not currently feasible there.
However, for other platforms (like my JtagDue clone), I guess you could always time-out an OpenOCD command if it takes too long to arrive in full.
I have noticed too that the Bus Pirate protocols and states are rather brittle: when you connect to the Bus Pirate, there is no reliable way to know what state it is currrently in, nor there is a dependable way to switch it to a known state.
If BPv4 has a new, reliable method, compatibility is not an issue here, as the user can always set an OpenOCD configuration option to indicate what (minimum) Bus Pirate version it is talking to.