Post by thread:[PIC] PIC16F690 EUSART Receiver not working, tran

All, I cannot get the receiver portion of a PIC16F690 EUSART to work. I can transmit fine, but am unable to receive characters. Since I can transmit, I'm assuming my baud rate generator settings are correct. I have checked the signal at the RX pin and it is good- correct polarity, correct baud rate, correct voltage level. I can see the RS232 signals arriving when sent from the PC. They compare exactly to those from the TX pin when the PIC is sending the same character. I tried using source code from your "PIC Specific RS232 IO" page by MaGahee et al. to no avail. (Love the code and comments btw- well done!) I tried using rs232.asm from Mark Torrens, also to no avail. I have a test board with only the PIC16F690 and a 3.6864MHz clock chip, so nothing else should be interfering, hardware-wise. I also built out two of the boards, so it probably isn't a fab issue. (I've got an external RS232 to TTL converter.) At one point I noticed that the FERR bit always seemed to get set, even if I cleared the queue and no characters were being sent to the PIC. I never saw OERR asserted, only the FERR signal. Any suggestions or help would be greatly appreciated- I've already wasted two days on this! Thanks, Tom p.s. Here's my setup code: __CONFIG _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _EC_OSC BANKSEL ANSEL CLRF ANSEL ; Digital I/O CLRF ANSELH ; Digital I/O BANKSEL TXSTA ; Select bank 1 CLRF TXSTA BCF TXSTA, TX9 ; Select 8-bit transmission BCF TXSTA, TXEN ; Disable transmission initially BCF TXSTA, SYNC ; Asynchronous mode ; BSF TXSTA, BRGH ; High baud rate BCF TXSTA, BRGH ; low baud rate since using extrnal 3.6864MHz clock. BANKSEL SPBRG MOVLW D'5' ; Baud rate counter value MOVWF SPBRG ; for 9600 baud, 3.6864MHz clock BANKSEL TXSTA BSF TXSTA, TXEN ; Enable transmission BANKSEL RCSTA BSF RCSTA, SPEN ; Enable serial port movlw 'B' btfss PIR1,TXIF goto $-1 movwf TXREG ; send character- this works

I'm sending the PIC signals through a MAX3232E chip. I've used the same circuit many times, and even with other PIC chips. And it's working fine when the PIC sends a character to the PC. When I hook a scope up to the RX pin of the PIC16F690 (Pin 12) I see a +5v marking signal as the default, and it spaces to 0 volts as I send a character from the PC. I should have mentioned that I hooked up the PICkit2 16F887 demo board to this same RS232-TTL converter, by removing the '690 from my board and jumpering wires from the '887 to the pads. I used much the same code as for the '690. This circuit worked, sending and receiving characters as expected. This has really got me stumped! Jan-Erik Soderholm wrote: {Quote hidden}> Tom Cassidy wrote: > > > >> (I've got an external RS232 to TTL converter.) >> > > Can you describe that in a little more detail. > That could be the key to this. What "converter" ? > And do ypou see the correct RS232 levels ? That is, > inverted from the USART levels ? > > >

I don't see a "BSF RCSTA, CREN" anywhere in your code, I think you need one. Cheers, Bob On Wed, 15 Apr 2009 15:04:27 -0500, "Tom Cassidy" <spam_OUTtomcTakeThisOuTfeatherstep.com> said: {Quote hidden}> All, > > I cannot get the receiver portion of a PIC16F690 EUSART to work. I can > transmit fine, but am unable to receive characters. > > Since I can transmit, I'm assuming my baud rate generator settings are > correct. > > I have checked the signal at the RX pin and it is good- correct > polarity, correct baud rate, correct voltage level. I can see the RS232 > signals arriving when sent from the PC. They compare exactly to those > from the TX pin when the PIC is sending the same character. > > I tried using source code from your "PIC Specific RS232 IO" page by > MaGahee et al. to no avail. (Love the code and comments btw- well done!) > > I tried using rs232.asm from Mark Torrens, also to no avail. > > I have a test board with only the PIC16F690 and a 3.6864MHz clock chip, > so nothing else should be interfering, hardware-wise. I also built out > two of the boards, so it probably isn't a fab issue. (I've got an > external RS232 to TTL converter.) > > At one point I noticed that the FERR bit always seemed to get set, even > if I cleared the queue and no characters were being sent to the PIC. I > never saw OERR asserted, only the FERR signal. > > Any suggestions or help would be greatly appreciated- I've already > wasted two days on this! > > Thanks, > Tom > > p.s. Here's my setup code: > __CONFIG _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & > _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _EC_OSC > > BANKSEL ANSEL > CLRF ANSEL ; Digital I/O > CLRF ANSELH ; Digital I/O > > BANKSEL TXSTA ; Select bank 1 > CLRF TXSTA > BCF TXSTA, TX9 ; Select 8-bit > transmission > BCF TXSTA, TXEN ; Disable transmission > initially > BCF TXSTA, SYNC ; Asynchronous mode > ; BSF TXSTA, BRGH ; High baud rate > BCF TXSTA, BRGH ; low baud rate since > using extrnal 3.6864MHz clock. > BANKSEL SPBRG > MOVLW D'5' ; Baud rate counter value > MOVWF SPBRG ; for 9600 baud, 3.6864MHz > clock > > BANKSEL TXSTA > BSF TXSTA, TXEN ; Enable transmission > BANKSEL RCSTA BSF RCSTA, > SPEN ; Enable serial port > > movlw 'B' > btfss PIR1,TXIF > goto $-1 > movwf TXREG ; send character- this works > > > > --

Sorry, should have included the meat of the code, too. It's from rs232.asm: You'll see the BSF RCSTA, CREN code in the "Receive" subroutine. BTW, the "DisplayCmd" routine works, and prints the message "Press a key:" on the PC. Thanks, Tom --------------------------------------------------------------------------- BANKSEL RCSTA BSF RCSTA, SPEN ; Enable serial port movlw 'B' btfss PIR1,TXIF goto $-1 movwf TXREG ; send character- this works ; ***************************************************************************** ; Main loop CALL DisplayCmd ; Display command message on terminal Loop CALL Receive ; Get input from terminal CALL DisplayOut MOVFW CHAR CALL Transmit GOTO Loop ; Keep reading until reset ; ***************************************************************************** ; Sub routines ; Receive a character Receive BSF RCSTA, CREN ; Enable reception WaitRec BTFSS PIR1, RCIF ; Character received? GOTO WaitRec ; No - wait MOVFW RCREG ; Get input character MOVWF CHAR RETURN Bob Blick wrote: {Quote hidden}> I don't see a "BSF RCSTA, CREN" anywhere in your code, I think you need > one. > > Cheers, > > Bob > > > On Wed, 15 Apr 2009 15:04:27 -0500, "Tom Cassidy" <.....tomcKILLspam@spam@featherstep.com> > said: > >> All, >> >> I cannot get the receiver portion of a PIC16F690 EUSART to work. I can >> transmit fine, but am unable to receive characters. >> >> Since I can transmit, I'm assuming my baud rate generator settings are >> correct. >> >> I have checked the signal at the RX pin and it is good- correct >> polarity, correct baud rate, correct voltage level. I can see the RS232 >> signals arriving when sent from the PC. They compare exactly to those >> from the TX pin when the PIC is sending the same character. >> >> I tried using source code from your "PIC Specific RS232 IO" page by >> MaGahee et al. to no avail. (Love the code and comments btw- well done!) >> >> I tried using rs232.asm from Mark Torrens, also to no avail. >> >> I have a test board with only the PIC16F690 and a 3.6864MHz clock chip, >> so nothing else should be interfering, hardware-wise. I also built out >> two of the boards, so it probably isn't a fab issue. (I've got an >> external RS232 to TTL converter.) >> >> At one point I noticed that the FERR bit always seemed to get set, even >> if I cleared the queue and no characters were being sent to the PIC. I >> never saw OERR asserted, only the FERR signal. >> >> Any suggestions or help would be greatly appreciated- I've already >> wasted two days on this! >> >> Thanks, >> Tom >> >> p.s. Here's my setup code: >> __CONFIG _FCMEN_OFF & _IESO_OFF & _BOR_OFF & _CPD_OFF & _CP_OFF & >> _MCLRE_ON & _PWRTE_ON & _WDT_OFF & _EC_OSC >> >> BANKSEL ANSEL >> CLRF ANSEL ; Digital I/O >> CLRF ANSELH ; Digital I/O >> >> BANKSEL TXSTA ; Select bank 1 >> CLRF TXSTA >> BCF TXSTA, TX9 ; Select 8-bit >> transmission >> BCF TXSTA, TXEN ; Disable transmission >> initially >> BCF TXSTA, SYNC ; Asynchronous mode >> ; BSF TXSTA, BRGH ; High baud rate >> BCF TXSTA, BRGH ; low baud rate since >> using extrnal 3.6864MHz clock. >> BANKSEL SPBRG >> MOVLW D'5' ; Baud rate counter value >> MOVWF SPBRG ; for 9600 baud, 3.6864MHz >> clock >> >> BANKSEL TXSTA >> BSF TXSTA, TXEN ; Enable transmission >> BANKSEL RCSTA BSF RCSTA, >> SPEN ; Enable serial port >> >> movlw 'B' >> btfss PIR1,TXIF >> goto $-1 >> movwf TXREG ; send character- this works >> >> >> >> --

On 15 Apr 2009 at 15:43, Tom Cassidy wrote: > I'm sending the PIC signals through a MAX3232E chip. I've used the same > circuit many times, and even with other PIC chips. And it's working > fine when the PIC sends a character to the PC. > > When I hook a scope up to the RX pin of the PIC16F690 (Pin 12) I see a > +5v marking signal as the default, and it spaces to 0 volts as I send a > character from the PC. > > I should have mentioned that I hooked up the PICkit2 16F887 demo board > to this same RS232-TTL converter, by removing the '690 from my board and > jumpering wires from the '887 to the pads. I used much the same code as > for the '690. This circuit worked, sending and receiving characters as > expected. > > This has really got me stumped! Sounds like software like you say. I'd be checking the precise order of initialisation, and TRIS status for the port lines according to the data sheet. I recently swapped the order of initialisation routines in a working '886 project thinking it wouldn't hurt anything - passed my own tests but a while later showed up problems in the field. Turned out if characters were being received WHILE the USART was being initialised it would send but not receive (or the other way round, can't remember exactly) and baud rate was sometimes messed up. It was hard to reproduce the symptoms, and debugging led me to my own comments in the code... "this shouldn't affect anything"! -- Brent Brown, Electronic Design Solutions 16 English Street, St Andrews, Hamilton 3200, New Zealand Ph: +64 7 849 0069 Fax: +64 7 849 0071 Cell: +64 27 433 4069 eMail: brent.brownKILLspamclear.net.nz

Brent, you seem to have hit on the answer! I reverted to an old version of my code and mixed the setup around a bit, and suddenly it started working! I think the trick was putting the ANSEL and ANSELH initialization earlier in the process, but I'm not positive since I moved a lot of things at once. I'm new to this site, so if there is any place I should post my working code and/or do something else to contribute to the global PIC knowledge base, please let me know. Thank you all for your suggestions, Tom Brent Brown wrote: {Quote hidden}> On 15 Apr 2009 at 15:43, Tom Cassidy wrote: > > >> I'm sending the PIC signals through a MAX3232E chip. I've used the same >> circuit many times, and even with other PIC chips. And it's working >> fine when the PIC sends a character to the PC. >> >> When I hook a scope up to the RX pin of the PIC16F690 (Pin 12) I see a >> +5v marking signal as the default, and it spaces to 0 volts as I send a >> character from the PC. >> >> I should have mentioned that I hooked up the PICkit2 16F887 demo board >> to this same RS232-TTL converter, by removing the '690 from my board and >> jumpering wires from the '887 to the pads. I used much the same code as >> for the '690. This circuit worked, sending and receiving characters as >> expected. >> >> This has really got me stumped! >> > > Sounds like software like you say. I'd be checking the precise order of initialisation, > and TRIS status for the port lines according to the data sheet. I recently swapped > the order of initialisation routines in a working '886 project thinking it wouldn't hurt > anything - passed my own tests but a while later showed up problems in the field. > Turned out if characters were being received WHILE the USART was being > initialised it would send but not receive (or the other way round, can't remember > exactly) and baud rate was sometimes messed up. It was hard to reproduce the > symptoms, and debugging led me to my own comments in the code... "this > shouldn't affect anything"! > >

Tom Cassidy wrote: > Brent, you seem to have hit on the answer! I reverted to an old version > of my code and mixed the setup around a bit, and suddenly it started > working! > > I think the trick was putting the ANSEL and ANSELH initialization > earlier in the process, but I'm not positive since I moved a lot of > things at once. Nice you've got it working. Generelly, I'd probably put the dig/analog settig of the pins before the init of the peripherials. I don't know why, it just seems as the logical order in some way... :-) {Quote hidden}> > I'm new to this site, so if there is any place I should post my working > code and/or do something else to contribute to the global PIC knowledge > base, please let me know. > > Thank you all for your suggestions, > Tom > > > Brent Brown wrote: >> On 15 Apr 2009 at 15:43, Tom Cassidy wrote: >> >> >>> I'm sending the PIC signals through a MAX3232E chip. I've used the same >>> circuit many times, and even with other PIC chips. And it's working >>> fine when the PIC sends a character to the PC. >>> >>> When I hook a scope up to the RX pin of the PIC16F690 (Pin 12) I see a >>> +5v marking signal as the default, and it spaces to 0 volts as I send a >>> character from the PC. >>> >>> I should have mentioned that I hooked up the PICkit2 16F887 demo board >>> to this same RS232-TTL converter, by removing the '690 from my board and >>> jumpering wires from the '887 to the pads. I used much the same code as >>> for the '690. This circuit worked, sending and receiving characters as >>> expected. >>> >>> This has really got me stumped! >>> >> Sounds like software like you say. I'd be checking the precise order of initialisation, >> and TRIS status for the port lines according to the data sheet. I recently swapped >> the order of initialisation routines in a working '886 project thinking it wouldn't hurt >> anything - passed my own tests but a while later showed up problems in the field. >> Turned out if characters were being received WHILE the USART was being >> initialised it would send but not receive (or the other way round, can't remember >> exactly) and baud rate was sometimes messed up. It was hard to reproduce the >> symptoms, and debugging led me to my own comments in the code... "this >> shouldn't affect anything"! >> >>