serial coms - again

[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