RCSTA1 issue?

[Christopher4187]

I'm using an 18F87J50 to communicate with another processor at 115K. Most of the time the communication works fine but sometimes it gets stuck and when it gets stuck it's stuck permanently. I'm fairly certain the other processor locks up because I see my data going out but nothing comes back.

Anyhow, never had a chance to really look into the problem until today and I'm left with two questions. What exactly does this mean and how do I fix it?

Every time the processors talk to each other, I had the 87J50 print out TXTSTA1/2 and RCSTA1/2. The data sheet seems to indicate an overrun error on RCSTA1. While it's not frequent, this does appear to be causing some problems. In laymans terms, does the overrun error (bit1) simply mean that the RX1 port can't handle the data quick enough? The part that confuses me is that when the most amount of data is coming in, the RX1 port is disabled. I only look for a few bits in a packet of 10 bytes or so.

If the overrun is the issue, how can I solve it? Will lowering the baud rate do the trick or do I have to implement flow control? Any other options available?

Here is a few loops from the communication:


1:

RX2: 10010000
TX2: 00100110
RX1: 10010010
TX1: 00100100

2:

RX2: 10010000
TX2: 00100110
RX1: 10010010
TX1: 00100100


3: Watchdog reset on remote processor

RX2: 10010000
TX2: 00100110
RX1: 10010000
TX1: 00100100

4:

RX2: 10010000
TX2: 00100110
RX1: 10010010
TX1: 00100100

5:

RX2: 10010000
TX2: 00100110
RX1: 10010010
TX1: 00100100

6: Watchdog reset on remote processor

RX2: 10010000
TX2: 00100110
RX1: 10010000
TX1: 00100100

7:

RX2: 10010000
TX2: 00100110
RX1: 10010000
TX1: 00100100

[richard]

RCSTA1.4=0 ;clear any rcsta error
RCSTA1.4=1

since you have posted no code there's not much to work on , but generally that will get things working again

[Christopher4187]

Yup, I did that. Like I said, I'm pretty sure the remote processor is the issue, just trying to identify why it's happening and how to limit the failures.

I receive with this:
IF RCSTA1.1 = 1 THEN
RCSTA1.4 = 0
RCSTA1.4 = 1
DAT_IN1 = RCREG1
IF PIR1.5 = 1 THEN DAT_IN1 = RCREG1
ENDIF

FOR X=1 TO 500
HSERIN1 1, DONE, [STR DAT1\1]
IF DAT1="@" THEN GOTO DONE
DAT[X]=DAT1
NEXT

[richard]

In laymans terms, does the overrun error (bit1) simply mean that the RX1 port can't handle the data quick enough?

not really , it means that the rx buffer is full and that a new byte has been received and ready to be buffered ---- but the buffer has not been read yet.

if the rx stream is continuous and you have no flow control then the buffer overflow condition will occur every time you take time out to process the rx data.
the higher the data rate the less time you have to process the data.

[richard]

there is also this define
DEFINE HSER_CLROERR 1

[Christopher4187]

there is also this define
DEFINE HSER_CLROERR 1

That I didn't have in my program. Does it matter where the define goes? If I'm understanding the manual correctly, I shouldn't have to use this any longer? Also, didn't see it mentioned in the manual but will the define clear RCSTA1 and RCSTA2?


IF RCSTA1.1 = 1 THEN
RCSTA1.4 = 0
RCSTA1.4 = 1
DAT_IN1 = RCREG1
IF PIR1.5 = 1 THEN DAT_IN1 = RCREG1
ENDIF

It still won't help my original problem but I'll try lowering the baud rate and see if that helps. If not, I guess flow control is needed.

[richard]

Does it matter where the define goes?
no defines can go anywhere but for readability most keep them altogether and before the main code begins
you have not specified the version of pbp used it may mattter
DEFINE HSER_CLROERR 1 is definitely a pbp3 define I'm not sure if it applies to pbp2.xx maybe someone else can verify or maybe even rtfm , my pbp2.6 book has been misplaced (again)

[HenrikOlsson]

Hi,
As far as I know DEFINE HSER_CLROERR 1 (for the second USART it's DEFINE HSER2_CLROERR 1) is available in PBP2.x as well. But, remember that it only "works" when you're actually using HSERIN, if you "drive" the USART manually (like when you do DAT_IN1 = RCREG1) it won't do anything and you'd need to check/clear the overrun flag manually. It all it does is clear the overrun error flag (if set), it won't do anything to actually prevent the overrun condition in first place.

The main issue here is most likely the overall structure of the program. The data needs to be read from the USART buffer before the next byte comes in, the "best" way to handle this (if you don't know when data is about to come in) is usually to use interrupts. I don't know how you're handling it in your program (I may have missed it).

/Henrik.

[Christopher4187]

As far as I know DEFINE HSER_CLROERR 1 (for the second USART it's DEFINE HSER2_CLROERR 1) is available in PBP2.x as well. But, remember that it only "works" when you're actually using HSERIN, if you "drive" the USART manually (like when you do DAT_IN1 = RCREG1) it won't do anything and you'd need to check/clear the overrun flag manually. It all it does is clear the overrun error flag (if set), it won't do anything to actually prevent the overrun condition in first place.Overruns aren't really a problem, except when that condition locks up the device. More importantly, you pointed out something I never caught onto. So there is a HSER@2_CLOERR 1 define.


The main issue here is most likely the overall structure of the program. The data needs to be read from the USART buffer before the next byte comes in, the "best" way to handle this (if you don't know when data is about to come in) is usually to use interrupts. I don't know how you're handling it in your program (I may have missed it).I use HSERIN/HSERIN2 to get all data and I use interrupts to get it. If I understand your post correctly, I can remove this:
IF RCSTA1.1 = 1 THEN
RCSTA1.4 = 0
RCSTA1.4 = 1
DAT_IN1 = RCREG1
IF PIR1.5 = 1 THEN DAT_IN1 = RCREG1
ENDIFAnd just use this:
DEFINE HSER_CLROERR 1Is that correct?

[HenrikOlsson]

Hi Christopher,
Yes I believe that's correct. I Think what that define does is add code "in front" of the actual HSERIN code so that it checks the overrun flag and, if set, takes care of it.

/Henrik.