serial coms - again

[HenrikOlsson]

Hi Malcolm,
You can get that error message when you've missed a comma somewhere in the HSERIN command, look carefully and I think you'll find it.

Anyway, I took a stab at it here and I think the following should do it:

'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 NormTemp[Counter]]
NEXT
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 AlarmLow[Counter]]
NEXT
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 AlarmHigh[Counter]]
NEXT
'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC2 StartHour[Counter], DEC2 StartMin[Counter]]
NEXT
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC2 StopHour[Counter], DEC2 StopMin[Counter]]
NEXT
'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 DropTemp[Counter]]
NEXT
'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC2 LightSetHR[Counter], DEC2 LightSetMN[Counter]]
NEXT
'-------------------------------------------------------------------------------

It seems to work, I wrote up a bit of code to re-send all the variable back to PC and it looks like in the attached screenshot. Note that I'm only sending the "S" and I'm not waiting for that final "Q" in your datastream.

/Henrik.

PS. Here's the code I used to send everything back to the terminal, might be good for further debugging:

HSEROUT ["-------------------------------",10]
For Counter = 0 to 3
    HSEROUT ["Normtemp ", #Counter, "   : ", DEC3 Normtemp[counter],10]
    HSEROUT ["AlarmHigh ",#Counter, "  : ", Dec3 AlarmHigh[Counter],10]
    HSEROUT ["AlarmLow ",#Counter, "   : ", Dec3 AlarmLow[Counter],10]
    HSEROUT ["Start ",#Counter, "      : ", Dec2 StartHour[Counter],":", DEC2 StartMin,10]
    HSEROUT ["Stop ",#Counter, "       : ", Dec2 StopHour[Counter],":", DEC2 StopMin,10]
    HSEROUT ["Droptemp ",#Counter,"   : ", DEC3 Droptemp[counter],10]
    HSEROUT ["Light set ",#Counter, "  : ", DEC2 LightSetHr, ":", Dec2 LightsetMn,10]
    HSEROUT ["-------------------------------",10]     
Next 
HSEROUT ["T H A T ' S   I T   M A L C O L M",10,10]

[HenrikOlsson]

Hello again,
I didn't see your latest message before posting my previous.

It's not a comma missing in your HSERIN statement, however I don't think DIG can be used with HSERIN, only with HSEROUT - I think.

[malc-c]

Henrik,

As always, thanks for your help - that works a treat - THANK YOU !!!!!

[malc-c]

Just thought you might like to see the final result. I just hope that others searching or working on serial communications can make use of all that has gone on in this thread

[malc-c]

Maybe I spoke too soon - seems that something corrupts the LCD after a set number of transfers.

Basically the PC applications sends a "Q" every 10 seconds which causes the PIC to respond by sending the stream of digits described above. On the 27th Q the LCD starts to display random characters, initially along the bottom line of the 4 line LCD.

Thinking it might be the application I used the serial port coms app from MCS and manually sent Q's to the PC. on the 27th the same thing happened....

Any ideas on where to start de-bugging ?

[HenrikOlsson]

Hi Malcolm,
Really hard to say. Is it repeatable, always 27 times? Is everything else OK, just the LCD acting up?

I think you're going to have to post some code.

[Jerson]

Hi Malc_c

I was curious to see this thread and got into this pretty late.

How big is the serial data packet that you send down to the PIC?
From the details you gave, I think you have problems PC->PIC (downstream)
If that is true, are you buffering your received characters on the PIC? If not, then the least you can do is make the PC space out the characters in time. Put a few mS gap between each character sent to the PIC to avoid losing characters on the PIC
How do you synch the receive to the start of the incoming stream of data? Do you have a synch character to look for?
It will be better to look over the whole code to find the problem.

Regards

[malc-c]

Hi and thanks for the advice. The PC application simply send "Q" to the PIC every 10 seconds. The PIC responds to the Q by sending the 100 odd digits for the variables as described in previous posts above. When the application is used to update or set the PIC, the application has an "update" button which sends an "S" followed by the same 100 odd digits, followed by a "Q" to read back the values just written. The application does not send variable data to the PIC at any other time.

I agree that it's difficult to diagnose what might be happening without the complete code - please drop me a PM with an e-mail address and I'll mail you the code.

[Jerson]

Hi Malcolm

PM sent. Just in case you don't get it, you can PM me

Regards

[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.

[malc-c]

Hi,

Regret that due to a bereavement in the family I've not had much of a chance to look at this over the past week. I would love to know why it's so repeatable, and why / how it's resetting the PIC.

Hopefully once the family matters are resolved I'll get back to this and we'll get to the bottom of this issue. I've just taken delivery of 6 PCB's I've had made in HK, and might try and occupy my self by assembling one of these next week then hook it up to see if this replicates the problem. At least this would then rule out a problem with the EasyPIC 5 board, although when I loaded up a version of the original code that used hyperterm to send the PID values this ran without issue for quiet some time. The only other thing I noticed last week, was that occasionally the RTC seemed to display totally wrong time (27:67:65 for example) so maybe the poling is screwing up the memory, or the timing of the I2C bus or something equally screwy ???

[malc-c]

Update,

I'm stumped as to why this is happening when the 27th byte is sent. To check if it was the sending of data that was the problem, I simply made the code jump to the TX part of the program and send the data, then pause a little while before returning to the main program loop. When I ran this the PIC ran fine, sending data over and over again.

So this would suggest that the trigger is something to do with the receiving side. But what ?

The code simply jumps to either the sub-routine that receives data and updates variables or the subroutine that sends data, depending if Q or S is received. What is significant about the 27th byte !

FIXED !!!!!

I have no idea if this is just murphy's law or it was something to do with the mix of gosubs / goto's but I've re-coded as follows and it seems to work (well it's sent over 35 bytes to the PIC and it hasn't yet restarted)

;----[check for data on com port] 

    FOR TempWD = 0 TO 10000
        IF RCIF THEN GOTO coms
        PauseUs 100
    NEXT TempWD
;--------------------------------

I then have the checking for Q or S

coms:
HSERIN [nTest]
    SELECT CASE nTest
    CASE "Q"                    ; if Q then send data to PC
    Goto Term_TX 
    CASE "S"
    goto Term_RX
return

Then the TX and RX simply jump back to the start of the main loop after sending or receiving data

Why placing the test for Q or S inside the RX bit caused the problem, when segregating it as a separate sub routine I have no idea... and I seem to recall I tried this the other week.... but guess I got lucky this time round