Searching \ for '[PIC]: PIC18 USART RX Data Corruption' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=usart
Search entire site for: 'PIC18 USART RX Data Corruption'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PIC18 USART RX Data Corruption'
2002\01\23@124809 by Jennifer Loiacono

flavicon
face
Jennifer Loiacono
President
Automaton Engineering, Inc.
P.O. Box 10282
Brooksville, FL 34603When receiving serial data on the PIC18C442, the value
is not reflected correctly in the RCREG reception register.  However, the
signal on the receiving PIC is perfect in terms of timing and accuracy.
Despite accurate signal levels, debugging RCREG immediately after data is
received reveals that the byte seems to flip back and forth.

e.g., a byte equal to 4 (dec) will oscillate between 4 and 32.  A byte equal
to 1 will oscillate between 1 and 128, etc.

Again, this value is being read immediately after reception (triggered by RX
interrupt), so it is highly unlikely that program code could be altering the
register after reception.

Has anyone seen a problem like this before, or perhaps have any ideas as to
its cause?  I have been stumped on this for a while, so ANY help would be
greatly appreciated!


Jennifer Loiacono
Automaton Engineering, Inc.
P.O. Box 10282
Brooksville, FL 34603

spam_OUTjenTakeThisOuTspamautomatonengineering.com
http://www.automatonengineering.com

voice:   (352) 796-7088
mobile: (352) 650-6433
fax:      (352) 796-0544




.....jenKILLspamspam@spam@automatonengineering.com
http://www.automatonengineering.com

voice:   (352) 796-7088
mobile: (352) 650-6433
fax:      (352) 796-0544

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\23@130937 by Martin Peach

flavicon
face
----- Original Message -----
From: "Jennifer Loiacono" <jenspamKILLspamAUTO-SERV.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Wednesday, January 23, 2002 12:35 PM
Subject: [PIC]: PIC18 USART RX Data Corruption


> Jennifer Loiacono
> President
> Automaton Engineering, Inc.
> P.O. Box 10282
> Brooksville, FL 34603When receiving serial data on the PIC18C442, the
value
> is not reflected correctly in the RCREG reception register.  However, the
> signal on the receiving PIC is perfect in terms of timing and accuracy.
> Despite accurate signal levels, debugging RCREG immediately after data is
> received reveals that the byte seems to flip back and forth.
>
> e.g., a byte equal to 4 (dec) will oscillate between 4 and 32.  A byte
equal
> to 1 will oscillate between 1 and 128, etc.
>
> Again, this value is being read immediately after reception (triggered by
RX
> interrupt), so it is highly unlikely that program code could be altering
the
> register after reception.
>
> Has anyone seen a problem like this before, or perhaps have any ideas as
to
> its cause?  I have been stumped on this for a while, so ANY help would be
> greatly appreciated!

It usually happens when the serial data is not in the right form before it
hits the PIC pin (wrong voltage levels, skewed pulses, parity bit
mismatch...): where is it coming from? Straight from a PC port? From an
optocoupler? from a rf receiver? Need more info.

/\/\/\/*=Martin

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\23@132429 by Jennifer Loiacono

flavicon
face
The transmission is from PIC to PIC - one USART to another.  The sending PIC
is a 16F627.  The scope readings show perfect 5V signals at 9600 baud.
There is no parity bit, only 8 data bits, plus start and stop bit.

Jen

> {Original Message removed}

2002\01\23@132438 by Raymond Liu

flavicon
face
It looks the receiving is randomly restarted during a reception. Check
software to see if there are somewhere access the serial port
unattentionally.

Raymond

{Original Message removed}

2002\01\23@145411 by Rudy Rudy

flavicon
face
Jen,

How do you 'print' out the data received?  By outputing them to LEDs?
Transmitting the received data again to a PC?  I am trying to see if
it's possibly the code.


Rudy


> The transmission is from PIC to PIC - one USART to another.  The
sending PIC
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\24@110611 by Jennifer Loiacono

flavicon
face
The value is transmitted (also via USART - possibly a clue?) to a serial
LCD.  The code is listed below.  All references to AARGBx, BARGBx, and
FXDxxxxxx registers/routines are part of the standard math libraries
provided by Microchip.  I have used them extensively, and they never SEEM to
cause any other problems.


;generic display routine

SERDISP BTFSS   TXSTA,TRMT              ;if transmit shift register full
       GOTO    SERDISP                 ;loop until ready
       BSF     TXSTA,TXEN              ;enable transmission
       MOVFF   CHARIN,TXREG            ;move new character into buffer
       RETURN


;display input value
LIMDISP                                 ;position cursor
       MOVLW   0xFE                    ;instruction character
       MOVWF   CHARIN
       CALL    SERDISP
       MOVLW   0x80                    ;position 1,0
       MOVWF   CHARIN
       CALL    SERDISP
       MOVLW   0x4C                    ;L
       MOVWF   CHARIN
       CALL    SERDISP
       MOVLW   0x49                    ;I
       MOVWF   CHARIN
       CALL    SERDISP
       MOVLW   0x4D                    ;M
       MOVWF   CHARIN
       CALL    SERDISP
       MOVLW   0x3A                    ;:
       MOVWF   CHARIN
       CALL    SERDISP

       ;divide by powers of 10 to get one decimal character at a time
       MOVFF   RCREG,AARGB0            ;move limit into dividend register
       MOVLW   0x64                    ;100d
       MOVWF   BARGB0                  ;move to divisor register
       CALL    FXD0808U                ;unsigned 8x8 division
       MOVLW   0x16                    ;load high byte of PC for table lookup vector
       MOVWF   PCLATH                  ;program counter latch high
       MOVF    AARGB0,W                ;move quotient to wreg for code lookup
       CALL    ASC_TBL                 ;lookup hex code for ascii character
       MOVWF   CHARIN                  ;move value to character holding register
       CALL    SERDISP                 ;display character
       MOVFF   REMB0,AARGB0            ;move remainder to use as next divisor
       MOVLW   0x0A                    ;10d
       MOVWF   BARGB0                  ;move to divisor register
       CALL    FXD0808U                ;unsigned 8x8 division
       MOVLW   0x16                    ;load high byte of PC for table lookup vector
       MOVWF   PCLATH                  ;program counter latch high
       MOVF    AARGB0,W                ;move quotient to wreg for code lookup
       CALL    ASC_TBL                 ;lookup hex code for ascii character
       MOVWF   CHARIN                  ;move value to character holding register
       CALL    SERDISP                 ;display character
       MOVLW   0x16                    ;load high byte of PC for table lookup vector
       MOVWF   PCLATH                  ;program counter latch high
       MOVF    REMB0,W                 ;move remainder to wreg for code lookup
       CALL    ASC_TBL                 ;lookup hex code for ascii character
       MOVWF   CHARIN                  ;move value to character holding register
       CALL    SERDISP                 ;display character

       MOVLW   0x20                    ;space
       MOVWF   CHARIN
       CALL    SERDISP

       RETURN


----- In Response To -----

Jen,

How do you 'print' out the data received?  By outputing them to LEDs?
Transmitting the received data again to a PC?  I am trying to see if
it's possibly the code.


Rudy


> The transmission is from PIC to PIC - one USART to another.  The
sending PIC
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\24@114730 by Peter Onion
flavicon
face
On 23-Jan-02 Jennifer Loiacono wrote:
> Jennifer Loiacono
> President
> Automaton Engineering, Inc.
> P.O. Box 10282
> Brooksville, FL 34603When receiving serial data on the PIC18C442, the value
> is not reflected correctly in the RCREG reception register.  However, the
> signal on the receiving PIC is perfect in terms of timing and accuracy.
> Despite accurate signal levels, debugging RCREG immediately after data is
> received reveals that the byte seems to flip back and forth.
>
> e.g., a byte equal to 4 (dec) will oscillate between 4 and 32.  A byte equal
> to 1 will oscillate between 1 and 128, etc.

I'm not quite clear on what you mean by " oscillate between 1 and 128".

If I've missunderstood then please ignore me, but it sounds to me that you
reading the RCREG multiple times for each recieved character ?

I'm pretty sure that isn't allowed by the PIC.  You should read RCREG
ONCE and ONLY ONCE for each recieved character.

RCREG should be read ONCE each time the RCIF bit in PIR1 is set. Reading RCREG
will reset this bit automagically ready for the next character.

Peter Onion.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\24@120030 by Jennifer Loiacono

flavicon
face
I tried debugging RCREG directly as a last resort.  Previously, I had been
moving the value out to another register first; thus, one read per
character.  However, the results are the same either way.

Jen

> {Original Message removed}

2002\01\24@120055 by Raymond Liu

flavicon
face
I would like to suggest you to narrow down the range to locate the bug. You
may bypass all communication-unrelated codes and focus on the serial port
operation. Just to verify the TX/RX is correct. One thing can try is keeping
sending an identical printable char to the receiver and let the receiver
display it as directly and quickly as possible. I still suspect the
receiving port is unintentionally accessed if the waveform to the receive
pin is correct.

Raymond

{Original Message removed}

2002\01\24@122050 by Raymond Liu

flavicon
face
Multiple reads of RCREG wouldn't change its content.

Look at the waveform of an '4' togather with the start/stop bits. If two
'4's are sent back-to-back and the receiver not interpret the start bit
properly, it could receive a '32'. Similar thing happens to '1' and '128'
depending on the interval between characters. So it is possible the
receiving was interrupted and restarted during a byte reception.

Raymond

{Original Message removed}

2002\01\24@124837 by Peter Onion

flavicon
face
On 24-Jan-02 Jennifer Loiacono wrote:
> I tried debugging RCREG directly as a last resort.  Previously, I had been
> moving the value out to another register first; thus, one read per
> character.  However, the results are the same either way.

Ok.  My understanding and conclusions were wrong !!

Peter.


----------------------------------
E-Mail: Peter Onion <EraseMEponionspam_OUTspamTakeThisOuTsrd.bt.co.uk>
Date: 24-Jan-02
Time: 17:07:32

This message was sent by XFMail
----------------------------------

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\24@172216 by Peter L. Peres

picon face
Maybe you have very fast ringing on the edges of the signal. You do not
say what board/drivers/etc you are using. Ringing is very likely with fast
signals on wirewrap and protoboards. However I have never seen a problem
like yours.

$0.02

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\24@172818 by Bob Barr

flavicon
face
On Thu, 24 Jan 2002 10:32:05 -0500, Jennifer Loiacono wrote:

>The value is transmitted (also via USART - possibly a clue?) to a serial
>LCD.  The code is listed below.  All references to AARGBx, BARGBx, and
>FXDxxxxxx registers/routines are part of the standard math libraries
>provided by Microchip.  I have used them extensively, and they never SEEM to
>cause any other problems.
>
>
>;generic display routine
>
>SERDISP BTFSS   TXSTA,TRMT              ;if transmit shift register full
>        GOTO    SERDISP                 ;loop until ready
>        BSF     TXSTA,TXEN              ;enable transmission
>        MOVFF   CHARIN,TXREG            ;move new character into buffer
>        RETURN
>

Sorry, but I've lost track of which processor this code is running on.

If it's the 16F627 that I've seen mentioned previously, note that
TXSTA and TXREG are in two different register banks, banks 1 and 0
respectively.
Please ignore this post if they're in the same bank on the processor
you're using.

Regards, Bob

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\24@213416 by Rudy Rudy

flavicon
face
Jen,

Instead of using the serial LCD, I would recommend trying to see if your
PIC18 got the correct serial data first (i.e. try limitting the # of data
transmission to find out where the error occurs).  You can try it by simply
outputting the byte received in RCREG into PORTB for example.  Hook up 8
LEDs there, and see if you get the correct data all the time, or it
alternates like you said before.  If it's correct, then we can rule out the
possibility of the error of serial reception.  If it's not, then, we can go
on from there.

-----------------------
Rudy Rudy
rudyspamspam_OUTrudyrudy.com
http://www.rudyrudy.com
-----------------------

> {Original Message removed}

2002\01\25@080639 by Peter Onion

flavicon
face
On 24-Jan-02 Raymond Liu wrote:
> Multiple reads of RCREG wouldn't change its content.

Yes it will IFF there are more characters waiting in the FIFO.

Peter.

----------------------------------
E-Mail: Peter Onion <@spam@ponionKILLspamspamsrd.bt.co.uk>
Date: 25-Jan-02
Time: 10:57:39

This message was sent by XFMail
----------------------------------

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\01\25@102303 by Andy Jancura

picon face
Hello Jen,

I see two points, where you may have something to do:

1)      ;divide by powers of 10 to get one decimal character at a time
       MOVFF   RCREG,AARGB0

probably an small test on data ready flag in RCReg is missing

2)
SERDISP BTFSS   TXSTA,TRMT              ;if transmit shift register full
       GOTO    SERDISP                 ;loop until ready
?!      BSF     TXSTA,TXEN              ;enable transmission
       MOVFF   CHARIN,TXREG            ;move new character into buffer
       RETURN

why you re-enable the tranceiver each time you send an char? May be the
read-modify-write is the reason.

Good luck.

A.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\01\25@120258 by Jennifer Loiacono

flavicon
face
Thanks, everyone for your help on this one.

All I needed was a delay between successive transmissions.  Back to back TX
would occasionally cause the receiving USART to misinterpret start/stop bits
as data bits should it miss anything in between.

The core process on the receiving PIC18 was a high priority interrupt that
MUST take precedence over support functions.  On the other hand, it was
unnecessary to transmit this data constantly, as it is seldom changed at
runtime.

Thanks again,
Jen

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2002\01\25@123250 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,
I'm going a bit of topic here but I'll remain within PIC domain trust me.
I don't have an answer for your exact question but instead some minor
questions.

From your code posting:
<snip>
     ;divide by powers of 10 to get one decimal character at a time
       MOVFF   RCREG,AARGB0            ;move limit into dividend register
       MOVLW   0x64                    ;100d
       MOVWF   BARGB0                  ;move to divisor register
       CALL    FXD0808U                ;unsigned 8x8 division
       MOVLW   0x16                    ;load high byte of PC for table
lookup vector
       MOVWF   PCLATH                  ;program counter latch high
       MOVF    AARGB0,W                ;move quotient to wreg for code
lookup
       CALL    ASC_TBL                 ;lookup hex code for ascii character
       MOVWF   CHARIN                  ;move value to character holding
register
       CALL    SERDISP                 ;display character
       MOVFF   REMB0,AARGB0            ;move remainder to use as next
divisor
       MOVLW   0x0A                    ;10d
       MOVWF   BARGB0                  ;move to divisor register
       CALL    FXD0808U                ;unsigned 8x8 division
       MOVLW   0x16                    ;load high byte of PC for table
lookup vector
       MOVWF   PCLATH                  ;program counter latch high
       MOVF    AARGB0,W                ;move quotient to wreg for code
lookup
       CALL    ASC_TBL                 ;lookup hex code for ascii character
       MOVWF   CHARIN                  ;move value to character holding
register
       CALL    SERDISP                 ;display character
       MOVLW   0x16                    ;load high byte of PC for table
lookup vector
       MOVWF   PCLATH                  ;program counter latch high
       MOVF    REMB0,W                 ;move remainder to wreg for code
lookup
       CALL    ASC_TBL                 ;lookup hex code for ascii character
       MOVWF   CHARIN                  ;move value to character holding
register
       CALL    SERDISP                 ;display character
<snip>

All this for translating an recevied byte to ascii represenatation ??
I'm very curious how many program cycles there are in this snippet,
can you measure it ? ( either simulate or place breaks at entry/exit
and check number of cycles in between ).

Anyway I would propose something like this instead:

;-------------------------------------------
;Fast binary to decimal conversion (0..255)
;
;Input: in W
;Temp: AARGB0
;Output one digit at a time, seq. Hund:Tens:Ones (real ASCII)
; pseudo routine SERDISP used for byte output
;
;
;
;Size: ? instructions
;Execution time (with return): ?
;
;25-January-2001 by Tony Kübek ****untested****
;
; Stripped (limited to 8-bit input, no digit ram) version of :
; www.piclist.com/techref/microchip/math/radix/b2a-16b3a2-ng.htm
; as per:
;8-July-2000 by Nikolai Golovchenko
;23-Aug-2001
;Based on 8bit BIN2BCD of Scott Dattalo
;-------------------------------------------

#define BYTE_OFFSET     0x30    ; start decimal ASCII numbers

bin2dec255fast
       movwf   AARGB0  ; save number
       swapf AARGB0, w   ;Add the upper and lower nibbles
       addwf AARGB0, w   ;to get the one's digit
       andlw 0x0F
       skpndc          ;Go through a binary to bcd
        addlw 0x16     ;conversion for just the one's
       skpndc          ;digit
        addlw 0x06
       addlw 0x06
       skpdc
        addlw -0x06

       btfsc AARGB0, 4   ;bit 4 is a special case
        addlw 0x16 - 1 + 0x6
       skpdc
        addlw -0x06

                       ;now adjust the ten's digit
       btfsc AARGB0, 5   ;2^5 = 32, so add 3 to the ten's
        addlw 0x30     ;digit if bit 5 is set

       btfsc AARGB0, 6   ;2^6 = 64, so add 6
        addlw 0x60     ;if bit 6 is set

       btfsc AARGB0, 7   ;2^7 = 128, so add 2 (the ten's
        addlw 0x20     ;digit) if bit 7 is set


       addlw 0x60      ;convert the ten's digit to bcd
     
                       ;if there's a carry, then the input
       skpc            ;was greater than 99.
       goto between_0_199
between_100_255
       ; number greater than 100
       addlw -0x60
       ; rotate top bit of input into carry to see if number is above 200
       rlcf    AARGB0,F
       movwf AARGB0    ; save tens and ones ( packed bcd )
       ; if carry set send hundred digit '2' else '1'
       movlw 0x31
       skpnc
       movlw 0x32
       ; and display the hundred digit
       CALL    SERDISP                 ;display character in w
       goto send_tens_ones
between_0_199
       ; number less than 200, hundred can only be '0' or '1'
       rlcf    AARGB0,F        ; save top bit into carry
       movwf AARGB0    ; save tens and ones ( packed bcd )
       movlw 0x30      
       skpnc
       movlw 0x31
       ; and display the hundred digit
       CALL    SERDISP                 ;display character in w
send_tens_ones
       ; prepare tens digit
       swapf   AARGB0,w              
       andlw   0x0f    ; strip top nibble
       addlw   BYTE_OFFSET ; make ascii
       ; and display the tens digit
       CALL    SERDISP                 ;display character in w
       ; prepare ones digit
       movf    AARGB0,w              
       andlw   0x0f
       addlw   BYTE_OFFSET ; make ascii
       ; and display the ones digit
       CALL    SERDISP                 ;display character in w
       ; done
       return
       

Perhaps some minor modifications are needed.
Optimisations can be plentiful, in particular if more ram are available.

/Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...