Searching \ for '[PIC] PIC16F690 EUSART Receiver not working, tran' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/ios.htm?key=usart
Search entire site for: 'PIC16F690 EUSART Receiver not working, tran'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC16F690 EUSART Receiver not working, tran'
2009\04\15@160429 by Tom Cassidy

flavicon
face
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



2009\04\15@162147 by Jan-Erik Soderholm

face picon face
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 ?


2009\04\15@164346 by Tom Cassidy

flavicon
face
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}

2009\04\15@170156 by Bob Blick

face
flavicon
face
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_OUTtomcTakeThisOuTspamfeatherstep.com>
said:
{Quote hidden}

> --

2009\04\15@171851 by Tom Cassidy

flavicon
face
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}

>> --

2009\04\15@172139 by Brent Brown

picon face
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.brownspamKILLspamclear.net.nz


2009\04\15@175638 by Tom Cassidy

flavicon
face
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}

2009\04\15@182001 by Jan-Erik Soderholm

face picon face
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}

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