CAPS+BREAK during loading may put Pico in unknown state, requiring reset
Opened this issue · 8 comments
CAPS+BREAK causing a "J" Device I/O error and the "heartbeat" stops.
Using the Pico Reset button is unreliable, sometimes restoring normal
operation but also sometimes causing further trouble. In these cases the
reset button appeared to restore normal operation but the next command
to the Pico crashed the system with a rapid flashing of the heartbeat and the
Pico then no longer responded to commands.
Resetting the Pico does not reset the Timex and resetting the Pico independently of the Timex is likely not a good state.
When resetting the Pico, wait until you see the 3-flash sequence showing that the Pico has booted successfully, then reset the Timex.
Please read my comment on issue #10. Again in this case, when the user hits Ctrl+Break in the middle of a transmission, there's no message TS->Pico that says "Stop sending data",; and even if there were, the Pico won't read it until finish sending the current batch of bytes.
The three blinks you see is the watchdog kicking-in and aborting the transmission on the TS Side. Of course, this is not a controlled stop, and some data can remain on the pipeline.
The best way to resume operation after the blinking is:
a) Issue a command that has short output (LOAD "tpi:path" is ideal) a couple of times and see if normal operation is resumed; or
b) In more severe cases, run this little program:
10 PRINT IN 14; " ";
20 OUT 14, 100
30 GOTO 10
This will emtpy the TX FIFO on the Pico, and send back many characters "d", that don't form any commands. When the program output is 0's, the TX FIFO is empty, and the LED should blink three times acknnowledging the wrong commands. Finally a LOAD "tpi:path" should solve the issue and restore the heartbeat.
Any improvements that can be suggested are welcome.
@rcalcagno how do you feel about the watchdog clearing the buffers?
If only we had about 1-2K more in EXROM... we could have a more robust communication and build in some error messages like "lost connection".
Well, the buffers ARE emtpied by the watchdog; that's the three blinks. Problem is, as this is an "emergency" procedure, sometimes the CTRL+BREAK happens in the middle of a transmission TS->Pico, which gets a wrong command. This is where LOAD "tpi:path" could help.
The true solution is as Gustavo pointed out, a separate control channel. But this is out of the equation, due to HW limitations. A close second would be (with proper modifying of the ROM) to acknlowledge each byte sent, by sending a CRC back for each received byte for example, and abort the Pico in a controlled manner upon receiving a bad bytes. This of course would half the TX speed, which is not particularly critic. But requires extensive ROM modifications.
Actually, and Gustavo is going to hate me for this, we do have 8k to spare in the EX-ROM chunk 1, waiting for someone brave in the heart to unleash all of its power.....
Ah, ok! For what it's worth, I'm loving getting this dump of the mind of Ricardo!
True, there's all that unused ROM space in the 2068... huge tracts of ROM!
https://www.youtube.com/watch?v=GPX-mW4l1rU
:) I make extensive remarks, so somebody might come up with a fresh look at this old problems....
I came across this bug also where holding shift and space/break causes a crash during load.
Well, as explained, sometimes the Pico can successfully recover from Ctrl+Break (heartbeat resumed) but sometimes it can't depending on where on the sequence Ctrl+Break is pressed. Pretty much what you'd expect if you hit Ctrl+Break during a phyisical tape load!
This could be overcome with Gustavo's full handshake implementation, that this board is lacking due to shortage of GPIOs. The new RP2350 with 48 GPIOs should give us the ability to implement that, use the SD Card in a dedicated bus, and some other new features. But for now, unfortunately there's no much room for improvement here.