I set TRISC to 0b.1100.0000 (0xC0) for both rx/tx as input. -Adam Jonathan Evans wrote: > > 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 ----- > From: "Wollenberg, Frank" > To: > Sent: Wednesday, April 19, 2000 11:03 AM > Subject: AW: RS232 / Comm problem with PIC16F877 > > Jonathan, > I have your code revisited and no failure detected. > The only principal difference compared to my UART rx/tx coding is the > initializing of RC6/7 port pins. I'm programming TxD as output and RxD as > input. I know, there was a thread on this list discussing that. Many > piclister has initialized the ports as input or output (i didn't remember). > Try my initializing coding, it's an iddea. > Frank > > > -----Urspr|ngliche Nachricht----- > > Von: Jonathan Evans [mailto:evansjon@LIVERPOOL.AC.UK] > > Gesendet: Mittwoch, 19. April 2000 11:16 > > An: > Betreff: 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: evansjon@liv.ac.uk > > LIVERPOOL L69 3GJ Fax: (+44)-(0)151-794-4540 > > United Kingdom (UK) Tel: (+44)-(0)151-794-4602 > > ==================================================================== > >