16F877A HSERIN problem

[RFsolution]

I'm using a 16f877 with max 232 at 4mhz

I'm having problems reading multiple variables in 1 Hserin string
It works, but after some times it hangs so I think there is a buffer overflow
What worries me is that when i measure with an osciloscope, there are pulses on portc.7 the UART RX even with no max232 chip connected ???

Here is a part of the code:

DEFINE HSER_RCSTA 90h ' enable serial port,
' enable continuous receive
'
define HSER_TXSTA 24h ' enable transmit,
' BRGH=1
'
define HSER_SPBRG 103 ' set baudrate to 2400
DEFINE HSER_CLOERR 1 ' automatic clear overrun error

TRISB = %00000000
'OPTION_REG.7 = 0 ' Enable PORTB pullups
TRISC = %10000000
TRISD = %00001111
TRISE = %000

loop:
Hserin 500,LCD,[wait ("TAR"),dec3 var1,wait ("ANT"),DEC3 var2,wait ("AUX"),DEC3 var3,wait ("EXT"),DEC3 var4]


LCD:
pause 10
Lcdout $fe, 1 ' Clear screen

Lcdout "VAR1: ",#VAR1," VAR2: ",#var2

Lcdout $fe, $c0, "VAR3: ",#VAR3," VAR4:",#VAR4

Goto loop

Any Idea ?

[RFsolution]

Hi all,

Still suffering the same problem, what I measured on the RX UART pin

are negative pulses aproximatly 25 uSecondes long or 40khz

Does it has something to do that I have to enable the Uart or stop other functions on this pin ?

See my software example below

Thanks all

[mister_e]

Try changing


DEFINE HSER_CLOERR 1 ' automatic clear overrun error

to


DEFINE HSER_CLROERR 1 ' automatic clear overrun error

the timeout may screw or not the whole thing, try to remove it first. Once you get it working, you may decide to use interrupt instead.

If it was for me, i would probably use a single WAIT and parse the whole string at the end to validate the result.

[RFsolution]

Hi Mister_E

Unfortunatly no solution

So i'm wondering if someone has a working code to receive multiple items
in a row via Serin including the full configuration for the 16F877A

I also changed the multiple Wait's by a single Wait statement and
some Skip 1 's

I also changed the baudrate to 2400bd as i was using a 4mhz clock

than I even changed the crystal to 20 mhz and set the define osc 20

I still measure the same pulses on the RX UART portc.7

So i think something might be wrong with the configuration

So No result i'm a bit lost now !!!

I hope the serial specialists can help me

Walter

[mister_e]

Who/what send the data to your PIC?

What about if you skip the MAX232 and use SERIN/SERIN2/DEBUGIN instead?

[RFsolution]

Hi

I use codestudio and it has a build in terminal program

Still dont see where those pulses on the RX port com from

Even if I disconnect the MAX232 there are some pulses

I really think there is a config problem, I also asked the question to Mel
from Melabs

Any hints Welcome

I even checked versions of PBP to be sure there are no updates
i'm using 1.43

[Ioannis]

How fast is the string repeated?

After the labels TAR, ANT, AUX, EXT the values are ASCII or BINARY coming?

Ioannis

[DynamoBen]

I think everyone is looking past an important hint here. Those pulses on the uarts RX pin. Those pulses could be read as data accidentally and cause a problem. I've been there before.

If you disable the UART, do the pulses disappear? What types of signals are near by (pin wise)? The goal is to find out what if anything connected to the pic or in the code would be causing the pulses you speak of. There is a chance this is just general noise if that is the case it needs to be suppressed.

[RFsolution]

Hi Dymoben and other

No other signals nearby, it is generated by the PIC itself, clean negative going
pulses aproximatly 25 uSecondes long or 40khz

Walter

[DynamoBen]

Start tearing the code apart, there has got be de something doing it. In short you shouldn't have a pulse on an RX pin. Very odd.

[Dave]

RFsolution, The problem is in the "DEFINE HSER_CLOERR 1 ' automatic clear overrun error " statement. PBP clears the error by disabling the port and re-enabling it the same way as using the statement: RCSTA.4 = 0 and then RCSTA.4 = 1. this command set disables the receiver and then re-enables it to clear an overflow error. It's in the data sheet for the processor you are using. To prevent seeing this pulse you should set the output pin's state to normally high before using it as an input for the usart mode.

Dave Purola,
N8NTA

[RFsolution]

Thanks,

I will give it a try

I'm sure that those pulse are in conflict with the received data comming
from the max232

So if understand each time i use HSERIN i should make the pin high before

or just Tris portc.7 at startup ?

[RFsolution]

Finally !!!

I found probably a solution.

A faulty max 232 was generating those pulse on the RXport
and disturbing the RXdata

Thanks to all untill now for all replys hints etc...

[DynamoBen]

Cool, I figured something odd was going on. Usually its the simple stuff. :)