serial coms - again

[malc-c]

Thanks,

Jerson, and Henrik for the PM's - I've responded via e-mail

Many thanks

[malc-c]

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

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.

[Jerson]

Hi Malcolm

Can you try to just slow down the updates to LCD to say once every second? Sometimes updating the LCD too quickly can cause such behaviour

Regards
Jerson

[malc-c]

Hi Malcolm

Can you try to just slow down the updates to LCD to say once every second? Sometimes updating the LCD too quickly can cause such behaviour

Regards
Jerson

do you mean in the section

DEFINE LCD_DREG  PORTB           ' LCD Data port
DEFINE LCD_DBIT  0               ' starting Data bit (0 or 4)
DEFINE LCD_EREG  PORTB           ' LCD Enable port
DEFINE LCD_EBIT  5               '     Enable bit  (on EasyPIC 5 LCD)
DEFINE LCD_RSREG PORTB           ' LCD Register Select port
DEFINE LCD_RSBIT 4               '     Register Select bit   (on EasyPIC 5 LCD)
DEFINE LCD_BITS  4               ' LCD bus size (4 or 8 bits)
DEFINE LCD_LINES 4               ' number of lines on LCD
DEFINE LCD_COMMANDUS 2000        ' Command delay time in us 
DEFINE LCD_DATAUS 50             ' Data delay time in us

or in the section that drop the data in

ShowLCD:
    LOOKUP pid_Channel,[$80,$C0,$89,$C9],Bvar       ; Find location
    LCDOUT $FE,Bvar,DEC1 pid_Channel+1,"= "         ; print to LCD     
    TempWD = TempC : GOSUB TempToLCD                ; display TempC
    LCDOUT $DF                                      ; deg symbol
    
     
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

timeH=(RTCHour>>4)                               'convert the BCD format of the hours register and store in variable timeH
timeH=(timeH &$03)*10
timeH=timeH+(RTCHour&$0F)

timeM=(RTCMin>>4)
timeM=(timeM &$07)*10
timeM=timeM+(RTCMin&$0F)                         'convert the BCD format of the mins register and store in variable timeM

LCDOut $FE,$D4+8,#setpoints(0)dig 2,#setpoints(0)dig 1,$FE,$D4+11,#setpoints(1)dig 2,#setpoints(1)dig 1  ' show current set temperatures
LCDOut $FE,$D4+14,#setpoints(2)dig 2,#setpoints(2)dig 1,$FE,$D4+17,#setpoints(3)dig 2,#setpoints(3)dig 1

[Jerson]

Hi Malc

I suspect the second section is going a bit fast for the lcd to keep up.

I normally slow down the updates to about twice a second to about once a second. This should iron out any timing issues with the LCD

Regards

[malc-c]

Well the stray "15" on the LCD seems to stem from the RTC as this doesn't happen when the module is un-plugged, and as I've seen it momentarily displays the wrong time, and the fact thta this happens on nearly every version of code, most of which has been fine in the past does suggest this is a hardware issue. However the PIC still reboots on the 27th Q.... Why is it always the 27th... that's what I can't figure out... and this is irrspective of what's used to communicate with the PIC

[HenrikOlsson]

Hi Malcolm,
How's it going? Have you been able to find any cause for the weired characters and lockup? It's interesting that it locks up in (what seems to be) such a repeatable manner.

/Henrik.