OK I'm at a loss - I don't know if it's the code that's the problem, the PIC, or the development board.

The corruption now appears to be limited to just the bottom line of the 4 x 20 LCD. I've noticed that it tends to over-write the clock that's down in the bottom left of the display

The normal display looks like


Yet sometimes at random time the clock got over-written for a split second and the sometime sets points will revert back to 00, like this, sometimes



This is even when running without the serial cable connected. When I've got the serial cable hooked up and the 27th Q is sent the PIC either reboots and the LCD screen looks like the one above, or it doesn't reboot but displays a scrolling garbage like



Thinking it might be a problem with the LCD I took the one out of my prototype controller that's been used to keep my snakes warm... this too displays the same issue when plugged into the EasyPIC5 board.

So.. I started loading the same version of HEX that has been running in the prototype for the past two months (which has the original coms DT wrote for use with Hyperterm and doesn't use the PC app Charles has produced) and that too over-wrote the clock leaving 15 after the minutes.

OK maybe the RTC module I'm using is causing the issue, possibly corrupting the values

Code:
I2CRead SDApin,SCLpin,$D0,$00,[RTCSec,RTCMin,RTCHour,RTCWDay,RTCDay,RTCMonth,RTCYear,RTCCtrl]  ; read DS1307 chip
If RTCHour.6=1 then
			
CounterA=(RTCHour>>4)&$01                           ' Work-Out 12 or 24 hour Display for Hours
else
CounterA=(RTCHour>>4)&$03
endif
CounterA=CounterA*10+(RTCHour&$0F)                  ' Display Hours appropriately for 12 or 24 hour Mode 
If RTCHour.6=1 then			
LCDOut $FE,$D4,#CounterA
else
LCDOut $FE,$D4,#CounterA Dig 1,#CounterA Dig 0
endif
LCDOut ":",#(RTCMin>>4)&$0F,#RTCMin&$0F
for arguments sake it could be writing 26:6415 (which once on setting the time I found the variables used to equal such stupid numbers) and the when it goes back to displaying 16:26 the 15 is left behind - no problem, I can simply add LCDOut $FE,$D4+5," " to over-write it... BUT this doesn't explain why when I send Q to the PIC manually via the Hyperterm program, or use Charlies PC application to poll the PIC that it re-boots on the 27th Q, even when the DS1307 module has been removed.

The way I can tell it reboots is that after all the initialization, the first thing the PIC does is jump to an "about" subroutine that simply displays the current version of the code on the LCD, then jumps to the main program loop, so it has to be reset to display this screen.

Note:
I've subsequently moved the section which reads the stored values for each variable so now when it reboots the set temperatures are no longer zeroed as shown in the second image.