RCSTA1 issue?


Closed Thread
Results 1 to 10 of 10

Thread: RCSTA1 issue?

  1. #1
    Join Date
    Oct 2005
    Location
    New Jersey
    Posts
    425

    Default RCSTA1 issue?

    I'm using an 18F87J50 to communicate with another processor at 115K. Most of the time the communication works fine but sometimes it gets stuck and when it gets stuck it's stuck permanently. I'm fairly certain the other processor locks up because I see my data going out but nothing comes back.

    Anyhow, never had a chance to really look into the problem until today and I'm left with two questions. What exactly does this mean and how do I fix it?

    Every time the processors talk to each other, I had the 87J50 print out TXTSTA1/2 and RCSTA1/2. The data sheet seems to indicate an overrun error on RCSTA1. While it's not frequent, this does appear to be causing some problems. In laymans terms, does the overrun error (bit1) simply mean that the RX1 port can't handle the data quick enough? The part that confuses me is that when the most amount of data is coming in, the RX1 port is disabled. I only look for a few bits in a packet of 10 bytes or so.

    If the overrun is the issue, how can I solve it? Will lowering the baud rate do the trick or do I have to implement flow control? Any other options available?

    Here is a few loops from the communication:

    Code:
    1:
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010010
    TX1: 00100100
    
    2:
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010010
    TX1: 00100100
    
    
    3: Watchdog reset on remote processor
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010000
    TX1: 00100100
    
    4:
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010010
    TX1: 00100100
    
    5:
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010010
    TX1: 00100100
    
    6: Watchdog reset on remote processor
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010000
    TX1: 00100100
    
    7: 
    
    RX2: 10010000
    TX2: 00100110
    RX1: 10010000
    TX1: 00100100

  2. #2
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    Code:
    RCSTA1.4=0  ;clear any rcsta error
    RCSTA1.4=1
    since you have posted no code there's not much to work on , but generally that will get things working again

  3. #3
    Join Date
    Oct 2005
    Location
    New Jersey
    Posts
    425


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    Yup, I did that. Like I said, I'm pretty sure the remote processor is the issue, just trying to identify why it's happening and how to limit the failures.

    I receive with this:
    Code:
     IF RCSTA1.1 = 1 THEN    
           RCSTA1.4 = 0          
           RCSTA1.4 = 1
           DAT_IN1 = RCREG1         
           IF PIR1.5 = 1 THEN DAT_IN1 = RCREG1  
        ENDIF              
    
    FOR X=1 TO 500
            HSERIN1 1, DONE, [STR DAT1\1]
            IF DAT1="@" THEN GOTO DONE
            DAT[X]=DAT1 
    NEXT
    Last edited by Christopher4187; - 9th April 2015 at 00:19.

  4. #4
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    In laymans terms, does the overrun error (bit1) simply mean that the RX1 port can't handle the data quick enough?
    not really , it means that the rx buffer is full and that a new byte has been received and ready to be buffered ---- but the buffer has not been read yet.

    if the rx stream is continuous and you have no flow control then the buffer overflow condition will occur every time you take time out to process the rx data.
    the higher the data rate the less time you have to process the data.

  5. #5
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    there is also this define
    DEFINE HSER_CLROERR 1

  6. #6
    Join Date
    Oct 2005
    Location
    New Jersey
    Posts
    425


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    there is also this define
    DEFINE HSER_CLROERR 1
    That I didn't have in my program. Does it matter where the define goes? If I'm understanding the manual correctly, I shouldn't have to use this any longer? Also, didn't see it mentioned in the manual but will the define clear RCSTA1 and RCSTA2?

    Code:
     IF RCSTA1.1 = 1 THEN    
           RCSTA1.4 = 0          
           RCSTA1.4 = 1
           DAT_IN1 = RCREG1         
           IF PIR1.5 = 1 THEN DAT_IN1 = RCREG1  
        ENDIF
    It still won't help my original problem but I'll try lowering the baud rate and see if that helps. If not, I guess flow control is needed.

  7. #7
    Join Date
    May 2013
    Location
    australia
    Posts
    2,383


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    Does it matter where the define goes?
    no defines can go anywhere but for readability most keep them altogether and before the main code begins
    you have not specified the version of pbp used it may mattter
    DEFINE HSER_CLROERR 1 is definitely a pbp3 define I'm not sure if it applies to pbp2.xx maybe someone else can verify or maybe even rtfm , my pbp2.6 book has been misplaced (again)

  8. #8
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    Hi,
    As far as I know DEFINE HSER_CLROERR 1 (for the second USART it's DEFINE HSER2_CLROERR 1) is available in PBP2.x as well. But, remember that it only "works" when you're actually using HSERIN, if you "drive" the USART manually (like when you do DAT_IN1 = RCREG1) it won't do anything and you'd need to check/clear the overrun flag manually. It all it does is clear the overrun error flag (if set), it won't do anything to actually prevent the overrun condition in first place.

    The main issue here is most likely the overall structure of the program. The data needs to be read from the USART buffer before the next byte comes in, the "best" way to handle this (if you don't know when data is about to come in) is usually to use interrupts. I don't know how you're handling it in your program (I may have missed it).

    /Henrik.

  9. #9
    Join Date
    Oct 2005
    Location
    New Jersey
    Posts
    425


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    As far as I know DEFINE HSER_CLROERR 1 (for the second USART it's DEFINE HSER2_CLROERR 1) is available in PBP2.x as well. But, remember that it only "works" when you're actually using HSERIN, if you "drive" the USART manually (like when you do DAT_IN1 = RCREG1) it won't do anything and you'd need to check/clear the overrun flag manually. It all it does is clear the overrun error flag (if set), it won't do anything to actually prevent the overrun condition in first place.
    Overruns aren't really a problem, except when that condition locks up the device. More importantly, you pointed out something I never caught onto. So there is a HSER@2_CLOERR 1 define.
    The main issue here is most likely the overall structure of the program. The data needs to be read from the USART buffer before the next byte comes in, the "best" way to handle this (if you don't know when data is about to come in) is usually to use interrupts. I don't know how you're handling it in your program (I may have missed it).
    I use HSERIN/HSERIN2 to get all data and I use interrupts to get it. If I understand your post correctly, I can remove this:
    Code:
    IF RCSTA1.1 = 1 THEN    
           RCSTA1.4 = 0          
           RCSTA1.4 = 1
           DAT_IN1 = RCREG1         
           IF PIR1.5 = 1 THEN DAT_IN1 = RCREG1  
        ENDIF
    And just use this:
    Code:
    DEFINE HSER_CLROERR 1
    Is that correct?

  10. #10
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: RCSTA1 issue?

    Hi Christopher,
    Yes I believe that's correct. I Think what that define does is add code "in front" of the actual HSERIN code so that it checks the overrun flag and, if set, takes care of it.

    /Henrik.

Similar Threads

  1. IF-THEN issue
    By jmgelba in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 12th February 2014, 23:09
  2. TMR1 issue
    By Lestat in forum General
    Replies: 6
    Last Post: - 29th August 2012, 16:41
  3. Timing issue
    By gadelhas in forum mel PIC BASIC Pro
    Replies: 9
    Last Post: - 29th November 2011, 15:13
  4. Code Issue - select case or 'if' issue - not sure why
    By jamie_s in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 7th October 2007, 09:52
  5. 16F877A issue
    By DynamoBen in forum Off Topic
    Replies: 9
    Last Post: - 31st August 2007, 05:15

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts