Serial port on Pi

Using a self-built low vector ROM from the 12-Feb tarball, with GPIO added to the ROM, I am encountering occasional but persistent serial errors.

The programme (a development of SatNav) is controlling a Witty Pi 2 via the IIC bus (asserting GPIO 4 to power off the computer and using the RTC alarm to power it back on at a scheduled time) as well as reading and writing the RTC it provides, again via the IIC bus, using the OLED module to write to an OLED display, again using the IIC bus, whilst reading from the serial port from a GPS hat.

Sometimes it starts up but only receives zero characters or top bit set characters from the serial input. In this case I just force an immediate shutdown and next time it powers on it all works again (nearly always). The log shows that about one in six power ons results in a malfunctioning serial port and only a few times do they occur in two successive start ups.

356305,175079,1602,&5612FD2F,&5612FD2F,Start at 16:55:01 alarm was ??:54:48 flag   - close at 16:54:59alarm set to ??:56:02
356306,175074,1602,&5612FD4C,&5612FD4C,Start at 16:56:15 alarm was ??:56:02 flag   - close at 16:56:14alarm set to ??:57:16
356308,175075,1602,&5612FD69,&5612FD68,Start at 16:57:29 alarm was ??:57:16 flag   - close at 16:57:28alarm set to ??:58:30
356306,175072,1602,&5612FD86,&5612FD85,Start at 16:58:43 alarm was ??:58:30 flag   - close at 16:58:42alarm set to ??:59:44
356306,175077,1602,&5612FDA3,&5612FDA2,Start at 16:59:57 alarm was ??:59:44 flag   - close at 16:59:56alarm set to ??:00:58
356298,175077,1602,&5612FDC0,&5612FDBF,Start at 17:01:11 alarm was ??:00:58 flag   - close at 17:01:11alarm set to ??:02:12
356300,175078,1602,&5612FDDD,&5612FDDC,Start at 17:02:25 alarm was ??:02:12 flag   - close at 17:02:25alarm set to ??:03:26
356307,175082,1602,&5612FDF9,&5612FDF9,Start at 17:03:39 alarm was ??:03:26 flag   - close at 17:03:36alarm set to ??:04:40
356304,175081,1602,&5612FE16,&5612FE16,Start at 17:04:53 alarm was ??:04:40 flag   - close at 17:04:51alarm set to ??:05:54
356308,175083,1602,&5612FE33,&5612FE33,Start at 17:06:07 alarm was ??:05:54 flag   - close at 17:06:05alarm set to ??:07:08
356315,175086,1602,&5612FE50,&5612FE50,Start at 17:07:21 alarm was ??:07:08 flag   - close at 17:07:19alarm set to ??:08:22
356315,175086,1602,&5612FE6D,&5612FE6D,Start at 17:08:35 alarm was ??:08:22 flag   - serial at 17:08:33 alarm set to ??:09:36
356302,175081,1602,&5612FE8A,&5612FE8A,Start at 17:09:49 alarm was ??:09:36 flag   - close at 17:09:48alarm set to ??:10:50
356308,175081,1602,&5612FEA7,&5612FEA6,Start at 17:11:03 alarm was ??:10:50 flag   - close at 17:11:02alarm set to ??:12:04
356312,175081,1602,&5612FEC4,&5612FEC3,Start at 17:12:17 alarm was ??:12:04 flag   - close at 17:12:16alarm set to ??:13:18
356327,175079,1602,&5612FEE1,&5612FEE0,Start at 17:13:31 alarm was ??:13:18 flag   - close at 17:13:30alarm set to ??:14:32
356306,175084,1602,&5612FEFE,&5612FEFD,Start at 17:14:45 alarm was ??:14:32 flag   - close at 17:14:45alarm set to ??:15:46
356306,175084,1602,&5612FF1A,&5612FF1A,Start at 17:15:59 alarm was ??:15:46 flag   - serial at 17:15:56 alarm set to ??:17:00
356306,175084,1602,&5612FF37,&5612FF37,Start at 17:17:13 alarm was ??:17:00 flag   - serial at 17:17:11 alarm set to ??:18:14
356299,175082,1602,&5612FF54,&5612FF54,Start at 17:18:27 alarm was ??:18:14 flag   - close at 17:18:25alarm set to ??:19:28
356314,175085,1602,&5612FF71,&5612FF71,Start at 17:19:41 alarm was ??:19:28 flag   - close at 17:19:39alarm set to ??:20:42
356302,175076,1602,&5612FF8E,&5612FF8E,Start at 17:20:55 alarm was ??:20:42 flag   - close at 17:20:53alarm set to ??:21:56
356320,175086,1602,&5612FFAB,&5612FFAB,Start at 17:22:09 alarm was ??:21:56 flag   - close at 17:22:08alarm set to ??:23:10
356303,175085,1602,&5612FFC8,&5612FFC8,Start at 17:23:23 alarm was ??:23:10 flag   - close at 17:23:22alarm set to ??:24:24
356307,175084,1602,&5612FFE5,&5612FFE4,Start at 17:24:37 alarm was ??:24:24 flag   - close at 17:24:36alarm set to ??:25:38
356307,175084,1602,&56130002,&56130001,Start at 17:25:51 alarm was ??:25:38 flag   - shutdown at 17:25:50

Interpreting the log: entries that say ‘serial’ mean it found zero and top bit set characters coming in the serial input so just forced a shutdown. An entry that says ‘close’ means that the GPS fix was within 50m of where the last known position was. Basically if it detects movement it satys on to log the distance. Loss of fix for 15 mins or no movement for 15 min goes back to switching off and waking up. The ‘flag’ means it was turned on with alarm 1 flagged, ‘force’ means it was turned on by push button. Otherwise the log entries are gridX,gridY,odometer,starttime,endtime,comments.

Horrible work around but it means that even with a start up after only one minute (the design idea is for a 30 min power off period) it cuts power consumption down from about 500mA (with HDMI) to 52mAh per hour. (Probably about 35mAh/h if not using HDMI.)

Is there any way (short of power off/on) to bring the serial port back to life?

Sometimes it starts up but only receives zero characters or top bit set characters from the serial input.

Are you absolutely sure it is starting up with the right baud rate and word format? Usually if the results are gibberish, that’s the cause.

Is there any way (short of power off/on) to bring the serial port back to life?

From the days of modems (so a very distant memory), if the input was unexpected nonsense, then read until there’s nothing more (discard it), set the baud rate and word format again, and then briefly toggle flow control to kick the hardware. This might have been something to do with a bug in the 6551 or maybe just cargo cult programming. ;-)

Something I have noticed is that my Pi (older ROM) spews debugging info to the serial port at boot, but if there’s nothing to catch that data, the serial port is then effectively dead and won’t work if connected to a PC and more data sent (ie DADebug). Maybe not related, but it seems…unusual. The expected behaviour would be the data evaporating (as there’s no flow control). Not the entire serial functionality evaporating!

Are you absolutely sure it is starting up with the right baud rate and word format? Usually if the results are gibberish, that’s the cause.

Well, sort of Yes. I have read the baud rate stop bits etc and it says they are the values that I had written to them when the programme started. There’s no handshaking.

Taking the computer (model a+/Witty Pi 2/GPS Hat) to an impromptu meeting of BARUG tonight is likely to be a useful exercise in debugging once I read the log to see what it did! It certainly turned itself on and off with no user intervention.

When testing for this issue I found that sometimes the first hundred or so received characters were corrupt, after which it corrected itself. I didn’t try looking any deeper to see where the problem was (but it was almost certainly a receiver-side problem, since the transmitter was already up and running for a few seconds before I started the receive app on the Pi)

Is there any way (short of power off/on) to bring the serial port back to life?

Changing the baud rate or data format will cause the UART to be stopped and started again. I think this will also flush the FIFOs.

I’ll try this. The corrupted characters were being received far less often than the normal traffic would be, taking ages to accumulate up to over a hundred so it didn’t seem to correct itself (at least not after an hour or so). I’ll try changing the baud rate (it thinks it is running at the correct rate so I’ll change it to something that is definitely wrong, then back to the right figure and see what happens). I can flush the buffer with *FX 21,1.

At present I start up the serial port with:

41660  SYS "OS_SerialOp",5,7,0:REM Baud rate to 9600
41670  SYS "OS_SerialOp",1,0:REM Set 8bit, 1 stop bit, no parity
41680  SYS "OS_SerialOp",0,&3E:REM Set no handshaking
41690  SYS "OS_Byte",2,2:REM Enable serial input buffer/kbd input
41700  REM Now read serial baud rate and error if wrong
41710  SYS "OS_SerialOp",5,-1 TO ,r1%:REM read baud rate
41720  IF r1%<>7 THEN ERROR 20,"Baud rate wrong="+STR$(r1%)
41730  SYS "OS_SerialOp",1,-1 TO ,r1%:REM read stop bits
41740  IF r1%<>0 THEN ERROR 20,"Stop bits wrong"
41750  SYS "OS_SerialOp",0,0,&FFFFFFFF TO ,r1%,r2%:REM read handshake
41760  IF (r1% AND &FFFF)<>&3E OR (r2% AND &FFFF)<>&3E THEN ERROR 20,"Hand shake wrong"+STR$~(r1% AND &FFFF)+"/"+STR$~(r2% AND &FFFF)

and on a start up where the serial doesn’t work, asking again what baud rate it thinks it is using gives the expected answer (9600baud).