Hello Tony,
I faced the same bug with the cylinder clock as with the IN-14 clock when connecting a GPS unit: when powering on, the GPS unit has not yet got a fix and the consequence is that the clock crashed (see my post on IN-14 clock detailing that :
viewtopic.php?f=14&t=70&start=10)
I found a workaround with some additional components around the GPS unit so that it transmits GPS strings on TxD only when a fix is OK (PPS signal active, one pulse per second)
But recently, I went deep into the code and finally I found the reason of the crash.
This is located in the "GPSdecodeHi" section:
The code does the following:
- checking the checksum, if yes:
- Decoding if the string countains RMC , if yes:
- extracting the 6 digit hhmmss
and this is where the bug is :
when the GPS has not yet got a fix, the string is like this: $GPRMC,,V,,,,,,,,,,N*53
There is no hhmmss in the string. So the code will extract "," instead of the hhmmss and after that, it will count 8 "," to position on the ddmmyy part that do not exist either, and it will go further than the end of string... and crash...
To fix that, I added a couple of instruction, checking if we have a "," instead of the hhmmss :
; correction (23/04/2018) to exit when GPS fix is not done yet
; when fix is not done the string is like this: $GPRMC,,V,,,,,,,,,,N*53
incf FSR0L,f
;Test if string is empty (GPS fix not done)
movlw ","
; "," means that the time bytes are not available (GPS fix not done)
xorwf INDF0,w
btfsc STATUS,Z
; Z=1 means that the string begins like this: "$GPRMC,," : the time bytes are not present
goto GPSdecodeX
;String with no time bytes, exit
decf FSR0L,f
; end of correction
I tested it and it works well, no more crash !
You will find the source code in attached file