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:
>
> 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: evansjon@liv.ac.uk
> LIVERPOOL   L69 3GJ                       Fax: (+44)-(0)151-794-4540
> United Kingdom (UK)                       Tel: (+44)-(0)151-794-4602
> ====================================================================