Searching \ for 'RS232 / Comm problem with PIC16F877' 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=rs232
Search entire site for: 'RS232 / Comm problem with PIC16F877'.

Truncated match.
PICList Thread
'RS232 / Comm problem with PIC16F877'
2000\04\19@052832 by Jonathan Evans

flavicon
face
Hello all,

We have a PIC16F877 ICD development board (from Microchip) which we use
with MPLAB (v5). We have been trying to develop the first stage of
serial line communication protocol for the PIC but are having the
most annoying problem - and I'm going round in circles with it.

I cannot seem to successfully receive characters. Transmission has proved
to be fine, but reception gives a constant FERR (framing error). I
understand that this is caused by the
"reception of STOP bit as 0 instead of 1".

I have attached a file (commtest.asm) to try and illustrate what we are
doing, and the register configuration we are trying. The program tries to
simply echo each character back to the RS232 line as it is received (we
are using a standard MAX233 device for the TTL->RS232 voltage conversion).



; ===============================================================
; commtest.asm
; ===============================================================

list p=16f877

; Include file, change directory if needed
 include "p16f877.inc"


; Start at the reset vector
 org 0x000
 nop
Start


Main

  call InitComm
  goto EchoTest

InitComm
     ; At first we didn't have the the PORTC / TRISC
     ; code (because the Microchip code doesn't
     ; mention them - but we have included them to try

  bcf STATUS,5     ; select BANK 0
  bcf STATUS,6
  movlw 0x00       ; Set PORTC to all ZEROS
  movwf PORTC

  bsf STATUS,5     ; Select BANK 1
  bcf STATUS,6

  movlw 0xC0       ; Select PORTC bits 6 & 7 to USART
  movwf TRISC

     ; We have tried a range of baud rates, included 300, 9600, 19.2K
     ; at both high and low clock rates (BRGH)
  movlw   0x0B
  movwf SPREG      ;SPERG = 11 (for 19.2K high speed)
  movlw 0x24       ;Set TXSTA for Async, High speed, 8 bit data
  movwf TXSTA
  bcf PIE1,TXIE    ;Disable Transmission Interrupt
  bcf PIE1,RCIE    ;Disable Receive Interrupt


  bcf STATUS,5     ; Select BANK 0
  bcf STATUS,6

  movlw 0x90       ; Set RXSTA for Async, 8 bit data
  movwf RCSTA

   return


EchoTest
  bcf STATUS,5      ; Select BANK 0
  bcf STATUS,6

RCIFloop
  btfss PIR1,RCIF   ; Loop, while RCIF = 0
  goto RCIFloop

  btfss RCSTA,FERR  ; Check for Frame-Error
  goto NoFRAMEError ; If no FERR then skip

  movf RCREG,0      ; Copy RCREG -> w

  ;bcf RCSTA,CREN   ; Tried this ... doeen't make difference
  ;bsf RCSTA,CREN   ; Clears error (flag CREN 0 then 1)
  goto TXIFloop     ; Jump to Transmission Loop

NoFRAMEError
  movf RCREG,0      ; Copy RCREG -> W

TXIFloop
  btfss PIR1,TXIF   ; Loop, while TXIF = 0
  goto TXIFloop

  movwf TXREG       ; Copy W -> TXREG
  goto RCIFloop     ; Jump to start of loop

  end
; ===============================================================



We have noticed the following which might help to identify the problem:

* We have confirmed the baud rate is correct using a scope and logic
analyser (we are using a clock freq of 3.6864 MHz).

* We seem to have no problem with transmission, all characters are correctly
received.

* The busy-wait on the RCIF flag seems to work correctly. The program will
wait forever until a character is sent to the PIC, at which point the
program continues immediately. This seems to indicate the detection of the
START bit is OK.

* The value of the RCREG is *always* 0x00. This is suspicious because I
understand we should see the bit pattern that was received, even if it is
marked as possible framing error.

* Because of the above, it has occured to me that since every bit is seen as
0, then the STOP might also and hence the FERR. However, I don't understand
why every bit is seen as 0 ... especially when the START bit transition from
1 -> 0 is detected OK.

* It has also occured to me that the "constant" zero problem might be
because the direction register of PORTC is incorrect (TRISC). However,
looking around similar code and playing with the value seems not to have
helped.

* We have played around with 9 bit data and 2 stop bits and confirmed with
the logic analyser that the timing of the stop bit sample seems to be
correct (i.e. after the data has ended and the line has returned to logic
HIGH).


Sorry for the length of this, but I am at a complete loss as to how to
proceed further. Any help or advice that anyone could give would be very
gratefully received.

Many thanks in advance,

Jonathan

====================================================================
Dr Jonathan Evans
Department of Electrical Engineering and Electronics
The University of Liverpool               E-Mail: spam_OUTevansjonTakeThisOuTspamliv.ac.uk
LIVERPOOL   L69 3GJ                       Fax: (+44)-(0)151-794-4540
United Kingdom (UK)                       Tel: (+44)-(0)151-794-4602
====================================================================

2000\04\19@070154 by Jonathan Evans

flavicon
face
Guten Tag Frank,

Thanks for replying to my message. I had already playing with the TRISC
register but after your message I have tried it again.

I have tried changing from

   TRISC = 0xC0
to
   TRISC = 0x80

Does this sound correct ? What values are other people using ?

However, it still doesn't work (no visible difference anyway).

Looking at the PIC16F877 data sheet it seems to imply that the direction reg
is automatically set by enabling the USART peripheral (SPEN) ... however
seem to be able you fiddle with it afterward.

I have tried changing the RX pin (RC7) to an output and the RCIF flag
doesn't seem to trigger on a start bit any longer.

Has anyone else come across this constant FERR problem ... it got to be
something simple ...

BTW, I forgot to mention last time that I swap the PIC for an identical one
and same problem (just in case it was a fault chip).

Thanks again,

Jonathan


{Original Message removed}

2000\04\19@102119 by M. Adam Davis

flavicon
face
I've checked your code against mine, and cannot see any reason why you are not
getting the serial info.  I imagine you've gone over the wiring multiple times,
but it almost seems like you have an electrical problem.  Perhaps RTS is going
into your RX?  It may (depending on handshaking) go low for the entire byte,
causing all zeros and a framing error.  Perhaps your interface circuit (max232
or other) is fried?

Jonathan Evans wrote:
{Quote hidden}

2000\04\19@102320 by M. Adam Davis

flavicon
face
I set TRISC to 0b.1100.0000 (0xC0) for both rx/tx as input.

-Adam

Jonathan Evans wrote:
{Quote hidden}

> {Original Message removed}

2000\04\19@111759 by Jonathan Evans

flavicon
face
Hi Adam,

Thanks for your message. Yep, it very odd indeed.

The MAX233 is fine, I can see the TX and RX signal both before and after.
I've also swapped the PIC itself with another identical unit and same
problem.

One thing though, I not using any handshaking ... should I? I only have a
RX/TX/GND lines. The PIC USART doesn't rely on the extra timing information
handshaking would provide would it ? I have seen other people's code that
uses RTS/CTS but implemented though some other port lines (used to enable /
disable various parts of the USART).

However, the specification document doesn't mention them so I assumed they
were optional. Are they ?

Thanks,

Jonathan

{Original Message removed}

2000\04\19@112833 by M. Adam Davis

flavicon
face
No, the PIC doesn't need or use handshaking in the hardware UART.  If you can
see the signal going into the PIC and verify that it is within parameters, then
you should be all set.

You should probably check other factors, then.  Put bypass caps on the PIC,
check the OSC2 and make sure the crystal is actually at 3.6864MHz, etc.

-Adam

Jonathan Evans wrote:
{Quote hidden}

> {Original Message removed}

2000\04\19@114454 by James Paul

flavicon
face
Guys,

Just a thought.  I know on a PC , the RS232 data is inverted by
the computer when transmitted, and reinverted when received by
the receiving system.  And, I see you you're not using a PC at
this time, but are you inadvertently (or purposely) inverting
the data, and trying to receive on the wrong edge?
Like I say, just a thought.

                                      Regards,

                                        Jim



On Wed, 19 April 2000, "M. Adam Davis" wrote:

{Quote hidden}

> > {Original Message removed}

2000\04\19@114911 by Kbek Tony

flavicon
face
Hi,
Just a thought:

>We have a PIC16F877 ICD development board (from Microchip) which we use
>with MPLAB (v5). We have been trying to develop the first stage of
>serial line communication protocol for the PIC but are having the
>most annoying problem - and I'm going round in circles with it.

Are You trying to use the uart while using the ICD at the same time ?
In that case a snip from the ICD User guide: "RB6 & RB7 reserved for
programming"

I sucks, doesn't it ? the one thing that's really hard to debug is
serial comm's
and in that case the ICD is useless. :-(

So to sum it up: Debugging/using/looking/fiddling/etc with the UART
while using the ICD is not allowed/impossible/etc.

Therefore I'm going to try to make an serial framework app (
as the exellent initiative from Thomas McGahee the other day )
for the 16F87xx ( with initialisation, buffers, terminator handling,
token parser, etc ), I just need more time :-) .....
Its a bit hard to debug, my ICD doesnt help me....


/Tony


Tony KŸbek, Flintab AB            
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: tony.kubekspamKILLspamflintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ

2000\04\19@120749 by Andrew Kunz

flavicon
face
part 0 3027 bytes
Tony,

The UART is on RC not RB.  RB 4-7 are the
interrupt-on-change-when-I-feel-like-it pins.

Andy










K

Ÿbek Tony <.....tony.kubekKILLspamspam.....FLINTAB.COM> on 04/19/2000 11:41:58 AM

Please respond to pic microcontroller discussion list <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
                                                                               
                                                                               
                                                                               


                                                             
                                                             
                                                             
To:      PICLISTspamspam_OUTMITVMA.MIT.EDU                              
                                                             
cc:      (bcc: Andrew Kunz/TDI_NOTES)                        
                                                             
                                                             
                                                             
Subject: Re: RS232 / Comm problem with PIC16F877            
                                                             








Hi,
Just a thought:

>We have a PIC16F877 ICD development board (from Microchip) which we use
>with MPLAB (v5). We have been trying to develop the first stage of
>serial line communication protocol for the PIC but are having the
>most annoying problem - and I'm going round in circles with it.

Are You trying to use the uart while using the ICD at the same time ?
In that case a snip from the ICD User guide: "RB6 & RB7 reserved for
programming"

I sucks, doesn't it ? the one thing that's really hard to debug is
serial comm's
and in that case the ICD is useless. :-(

So to sum it up: Debugging/using/looking/fiddling/etc with the UART
while using the ICD is not allowed/impossible/etc.

Therefore I'm going to try to make an serial framework app (
as the exellent initiative from Thomas McGahee the other day )
for the 16F87xx ( with initialisation, buffers, terminator handling,
token parser, etc ), I just need more time :-) .....
Its a bit hard to debug, my ICD doesnt help me....


/Tony


Tony K

Ÿbek, Flintab AB
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: @spam@tony.kubekKILLspamspamflintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ


2000\04\19@122226 by Jonathan Evans

flavicon
face
Hi,

So are we saying that the RB6 & RB7 problem limits use of the USART (which I
thought was only on RC6 and RC7). Transmission seems to work OK, but
Reception ...

I have noticed though that the USART flags TXIF and RCIF never change state
in STEP mode. I have therefore been running the code without
debug-interruption.

Is there some other flag / MPLAB setting which I must change to prevent it
interferring with the USART ... or is it impossible to use the ICD
development kit for Serial comms (seems unlikely ... especially since there
is room for a MAX232 and DB9 connection on the development board).

Thanks,

Jonathan


{Original Message removed}

2000\04\19@142013 by Kbek Tony

flavicon
face
>Tony,

>The UART is on RC not RB.  RB 4-7 are the
>interrupt-on-change-when-I-feel-like-it pins.

>Andy

OOoops...
sorry You are entirely correct, RB6 & RB7 has nothing to do with the
uart
when concerning the pic, my project however needed these for
other communication related issues so I had 'this in my head' when
writing the un-thoughtful mail.
Again sorry to all thoose on the list,

ICD does help when using the internal UART :-)


/Tony


Tony KŸbek, Flintab AB            
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ
E-mail: KILLspamtony.kubekKILLspamspamflintab.com
ÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓÓ

2000\04\19@153537 by James Paul

flavicon
face
Jonathan,

Have you figured out anything yet?  I was just curious as I
seen the discussion fall off the list.

                                     Regards,

                                       Jim



On Wed, 19 April 2000, Jonathan Evans wrote:

{Quote hidden}

> {Original Message removed}

2000\04\19@154744 by M. Adam Davis

flavicon
face
I have the next few days off.  If I have time, I'll use my ICD (homebuilt) to
program the 16f877 with very basic serial code, and test it out.  When it works
(it'll work, if it knows what's good for it!) I'll send you the asm file, and
you can see if it works similarily on yours.

If it doesn't work, then at least I can spend some time debugging it.

-Adam

Jonathan Evans wrote:
{Quote hidden}

2000\04\20@054314 by Claudio Rachiele IW0DZG
flavicon
face
Jonathan, the following code in not all mine.
I have copied it from net and it doesn't work. I have debugged it until
everything works.
Hope this can help you.

    Title  "USART TESTER"
    ;
    ; Author  Claudio RACHIELE IW0DZG
    ;
    ; Working  20000318
    ;
    list p=16f877,c=140    ; processor type
    errorlevel          1, -(305)
    #include "p16f877.inc"
    __CONFIG  _PWRTE_ON&_HS_OSC&_LVP_OFF&_WDT_OFF

temp  equ   7Fh               ;
;
; -----------
; DESCRIPTION
; -----------
;
; Baud Rate = 9600, No Parity, 8 bits & 1 Stop Bit
;
; -------------
; PROGRAM START
; -------------
;
    org  0         ; startup = 0000H
    clrf STATUS         ; bank 0
    goto BootStart
    org  4
ISR  goto 5         ;
    org  5
;
; --------------------------------------------------
; SET UP THE PORTS TO SUIT YOUR CIRCUIT REQUIREMENTS
; --------------------------------------------------
;

BootStart
    banksel PORTA       ; bank0
    movlw     b'00000000'
    movwf     PORTA
    movlw     b'00000000'
    movwf     PORTB
    movlw     b'01000000'
    movwf     PORTC
    movlw     b'00000000'
    movwf     PORTD
    movlw     b'00000000'
    movwf     PORTE

    banksel TRISA       ; bank1
    movlw     b'00000001'
    movwf     TRISA
    movlw     b'00000000'
    movwf     TRISB
    movlw     b'11000000'    ; set RC6 & RC7 as input
    movwf     TRISC
    movlw     b'00000000'
    movwf     TRISD
    movlw     b'11101000'
    movwf     TRISE
    movlw     b'00000111'
    movwf     ADCON1         ; porta inputs = digital not analog
;
; BAUD RATE SETTINGS
;
                   ;  Baud Values with BRGH = 0
                   ;  ((20000000/9600)/64)-1 = 32
;    movlw     d'207'    ;  1200 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'103'          ;  2400 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'25'           ;  9600 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'12'           ; 19200 baud @ 16 Mhz Fosc +0.16 err
;    movlw     d'255'          ;  1200 baud @ 20 Mhz Fosc +1.73 err
;    movlw     d'129'          ;  2400 baud @ 20 Mhz Fosc +0.16 err
;    movlw     d'32'          ;  9600 baud @ 20 Mhz Fosc -1.36 err
;    movlw     d'15'          ; 19200 baud @ 20 Mhz Fosc +1.73 err

                   ;  Baud Values with BRGH = 1
                   ;  ((20000000/9600)/16)-1 = 32
    movlw     d'129'         ;  9600 baud @ 20 Mhz Fosc +0.16 err
    movwf     SPBRG
    movlw     b'00100100'    ; brgh = 1
    movwf     TXSTA           ; enable Async Transmission, set brgh
    banksel RCSTA       ; bank0
    movlw     b'10010000'
    movwf     RCSTA          ; enable Async Reception
    movf RCREG,w
    movf RCREG,w
    movf RCREG,w        ; flush receive buffer
;
;
; ------------------------------------
; PROVIDE A SETTLING TIME FOR START UP
; ------------------------------------
;
    clrf temp
Settle
    decfsz  temp
    goto Settle

LWaitCom
    call      RecLoop         ; wait and read from RS232
    movwf     PORTB          ; show value for diagnostic purpose
TxLoop
    nop
    btfss     PIR1,TXIF ;xmit buffer empty?
    goto TxLoop         ;no, wait

    movwf     TXREG

    goto LWaitCom  ; no
;
; ----------------------------
; RECEIVE CHARACTER FROM RS232
; ----------------------------
; This routine does not return until a character is received.

RecLoop
    nop
    btfss     PIR1,RCIF ; check for received data
    goto RecLoop
    movf RCREG,w
    return
    end

CIAO
                      Claudio Rachiele IW0DZG


Jonathan Evans <spamBeGoneevansjonspamBeGonespamLIVERPOOL.AC.UK> on 04/19/2000 11:15:49 AM

Please respond to pic microcontroller discussion list
     <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU>

To:   undisclosed-recipients:;, RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU
cc:    (bcc: Claudio Rachiele IW0DZG/Italy/IBM)
Subject:  RS232 / Comm problem with PIC16F877




Hello all,

We have a PIC16F877 ICD development board (from Microchip) which we use
with MPLAB (v5). We have been trying to develop the first stage of
serial line communication protocol for the PIC but are having the
most annoying problem - and I'm going round in circles with it.

I cannot seem to successfully receive characters. Transmission has proved
to be fine, but reception gives a constant FERR (framing error). I
understand that this is caused by the
"reception of STOP bit as 0 instead of 1".

I have attached a file (commtest.asm) to try and illustrate what we are
doing, and the register configuration we are trying. The program tries to
simply echo each character back to the RS232 line as it is received (we
are using a standard MAX233 device for the TTL->RS232 voltage conversion).



; ===============================================================
; commtest.asm
; ===============================================================

list p=16f877

; Include file, change directory if needed
 include "p16f877.inc"


; Start at the reset vector
 org 0x000
 nop
Start


Main

  call InitComm
  goto EchoTest

InitComm
     ; At first we didn't have the the PORTC / TRISC
     ; code (because the Microchip code doesn't
     ; mention them - but we have included them to try

  bcf STATUS,5     ; select BANK 0
  bcf STATUS,6
  movlw 0x00       ; Set PORTC to all ZEROS
  movwf PORTC

  bsf STATUS,5     ; Select BANK 1
  bcf STATUS,6

  movlw 0xC0       ; Select PORTC bits 6 & 7 to USART
  movwf TRISC

     ; We have tried a range of baud rates, included 300, 9600, 19.2K
     ; at both high and low clock rates (BRGH)
  movlw   0x0B
  movwf SPREG      ;SPERG = 11 (for 19.2K high speed)
  movlw 0x24       ;Set TXSTA for Async, High speed, 8 bit data
  movwf TXSTA
  bcf PIE1,TXIE    ;Disable Transmission Interrupt
  bcf PIE1,RCIE    ;Disable Receive Interrupt


  bcf STATUS,5     ; Select BANK 0
  bcf STATUS,6

  movlw 0x90       ; Set RXSTA for Async, 8 bit data
  movwf RCSTA

   return


EchoTest
  bcf STATUS,5      ; Select BANK 0
  bcf STATUS,6

RCIFloop
  btfss PIR1,RCIF   ; Loop, while RCIF = 0
  goto RCIFloop

  btfss RCSTA,FERR  ; Check for Frame-Error
  goto NoFRAMEError ; If no FERR then skip

  movf RCREG,0      ; Copy RCREG -> w

  ;bcf RCSTA,CREN   ; Tried this ... doeen't make difference
  ;bsf RCSTA,CREN   ; Clears error (flag CREN 0 then 1)
  goto TXIFloop     ; Jump to Transmission Loop

NoFRAMEError
  movf RCREG,0      ; Copy RCREG -> W

TXIFloop
  btfss PIR1,TXIF   ; Loop, while TXIF = 0
  goto TXIFloop

  movwf TXREG       ; Copy W -> TXREG
  goto RCIFloop     ; Jump to start of loop

  end
; ===============================================================



We have noticed the following which might help to identify the problem:

* We have confirmed the baud rate is correct using a scope and logic
analyser (we are using a clock freq of 3.6864 MHz).

* We seem to have no problem with transmission, all characters are
correctly
received.

* The busy-wait on the RCIF flag seems to work correctly. The program will
wait forever until a character is sent to the PIC, at which point the
program continues immediately. This seems to indicate the detection of the
START bit is OK.

* The value of the RCREG is *always* 0x00. This is suspicious because I
understand we should see the bit pattern that was received, even if it is
marked as possible framing error.

* Because of the above, it has occured to me that since every bit is seen
as
0, then the STOP might also and hence the FERR. However, I don't understand
why every bit is seen as 0 ... especially when the START bit transition
from
1 -> 0 is detected OK.

* It has also occured to me that the "constant" zero problem might be
because the direction register of PORTC is incorrect (TRISC). However,
looking around similar code and playing with the value seems not to have
helped.

* We have played around with 9 bit data and 2 stop bits and confirmed with
the logic analyser that the timing of the stop bit sample seems to be
correct (i.e. after the data has ended and the line has returned to logic
HIGH).


Sorry for the length of this, but I am at a complete loss as to how to
proceed further. Any help or advice that anyone could give would be very
gratefully received.

Many thanks in advance,

Jonathan

====================================================================
Dr Jonathan Evans
Department of Electrical Engineering and Electronics
The University of Liverpool               E-Mail: evansjonEraseMEspam.....liv.ac.uk
LIVERPOOL   L69 3GJ                       Fax: (+44)-(0)151-794-4540
United Kingdom (UK)                       Tel: (+44)-(0)151-794-4602
====================================================================

2000\04\21@104417 by M. Adam Davis

flavicon
face
I set TRISC to 0b.1100.0000 (0xC0) for both rx/tx as input.

-Adam

Jonathan Evans wrote:
{Quote hidden}

> {Original Message removed}

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