• AVR Freaks

Hot!PIC16F15323 EUSART Async RX timing (framing error)

Author
PointOnePA
New Member
  • Total Posts : 15
  • Reward points : 0
  • Status: offline
2020/04/07 09:12:22 (permalink)
0

PIC16F15323 EUSART Async RX timing (framing error)

I've got a trivial RS232 serial test routine running on a PIC16F15323 that plugged into a Curiosity board.  It is programmed using the low voltage mode with MPLAB IDE V5.30 and XC8 (V2.10).  I've set it up for 9600N81 and it correctly transmits data to a PC using a TTL_RS232 to USB converter.   However, when I attempt to receive and then echo data sent to the PIC, the PIC does not receive the data being sent correctly.  It appears to have a clock timing issue that I've not be able to resolve.  I've verified that the data being sent is correct using another serial port and also a logic analyzer.  I've verified that data is incorrect in RC1REG and I can see that the framing error flag is being set FERR.   I'm using the MPLAB Code Configurator V3 to generate the code.   I've attempted to tweak the baud rate, but that didn't work.  I then attempted to use OSCTune to adjust the clock, but I didn't see any difference there either.   I checked the forum and saw some other UART posted regarding framing error, but none that I thought were related.  I'm using a 1MHz Fosc clock, so 1E6/4/26 ~ 9615baud

Here's the guts of the MPLAB Code Configurator eusart1.c initialization.
    // ABDOVF no_overflow; SCKP Inverted; BRG16 16bit_generator; WUE disabled; ABDEN disabled;
    BAUD1CON = 0x18; //BRG16 =1
    // SPEN enabled; RX9 8-bit; CREN enabled; ADDEN disabled; SREN disabled;
    RC1STA = 0x90;
    // TX9 8-bit; TX9D 0; SENDB sync_break_complete; TXEN enabled; SYNC asynchronous; BRGH hi_speed; CSRC slave;
    TX1STA = 0x24; //BRGH =1
    // SP1BRGL 25;
    SP1BRGL = 0x19; //0x19 = 25 decimal. add 1 for baud calculation.
    // SP1BRGH 0;
    SP1BRGH = 0x00;

 
The main program is just a serial echo loop using the code from the Code Configurator.
     if(EUSART1_is_rx_ready() ) // check if data in buffer. Interrupt fills this buffer
     { i = EUSART1_Read(); // read the data from the buffer
            __delay_ms(200);
            EUSART1_Write(i); // write the data back out.
     }
        __delay_ms(200);



The incorrect data I'm seeing:
SENT           RECEIVED
"U"  0x55      0x55         correct
"V"  0x56      0x2A
"W"  0x57      0x54
"X"  0x58      0x0A
"1"  0x31      0x67
 
I know that reading the RC1REG will clear the framing error, but when the error occurs, I also tried to disable the serial using SPEN, the re-enable it.  That didn't help.   I can attempt to use AutoBaud, but I've never had an issue like this with microcontroller RS232 before so I'm hoping that I'm just missing something that someone else has experienced previously.

I suppose the next thing I'll try is skip the code configurator and just use a simple one file program to see if that works.
I just thought I would ask in case someone has seen this before or I'm missing something obvious.
 
 
#1

19 Replies Related Threads

    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 09:42:19 (permalink)
    0
    I forgot to mention that the PPS appears to be set correctly in the pin_manager.c file:
        RC4PPS = 0x0F;     //RC4->EUSART1:TX1;    
        RX1DTPPS = 0x15;   //RC5->EUSART1:RX1;  
     
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 18655
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 09:44:17 (permalink)
    +1 (1)
         { i = EUSART1_Read(); // read the data from the buffer
                __delay_ms(200); // why is this here?
                EUSART1_Write(i); // write the data back out.
         }
    Your Delay will cause Buffer over runs. 200 ms is 5 chars per second. (55 baud) Unless you are typing slowly by hand.
    If you are thinking you are getting a Framing error, then you should check the Framing error flag.
    You need to add error checking and handling.
    I assume the Number of start, stop and parity bits is the same on the PC.
    #3
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 10:03:45 (permalink)
    0
    Yes, I'm typing by hand.  I'm manually sending one byte at a time AND I have breakpoints set in the RX interrupt.
    Also, the serial RX buffer on the PIC16F15323 is 16-bit, so it can hold 2 bytes.
    So the delay should have no bearing on my question.
     
    I mentioned in the post that I am getting a framing error which I trap and detect in the interrupt.
    Just as a precaution, I also checked the overruns.  So the error checking already exist.  
    What I'm trying to resolve is WHY there is a framing error at all.
     
    I believe the PIC is configured for a single stop bit, but using the PC program I've attempted 1, 1.5,2 stop bit with no difference in the result.
     
    #4
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 11:09:52 (permalink)
    0
    I'm guessing the issue that I'm having has to do with low-voltage programming mode on the Curiosity board.  Every time I power down/shutdown and restart I get a message from MPLAB-X telling me that the low-voltage programming on the CHIP/IC is disabled and I cannot program it.  That should NOT be possible with the Curiosity board, but I'm guessing some how the serial port connection is toggling voltages, (ground loop maybe).  So I'll have to get a PICkit4 and see if that clears both the low voltage programming AND this serial framing error.   But they are on back-order, so that'll take a while.   Argh!
     
     
     
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 18655
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 11:11:00 (permalink)
    0
    are both set to 8,N,1?  If you have Framing errors it is either the Baud Rate or the wrong number if bits in the byte.
    You can look at the Baud Rate with a Scope a capital 'U' is a Good Gauge.  But being the first byte is correct, I would Guess your Number of bits, Parity, or Stop bits is wrong.  8,N,1 is common.  Start there.
    #6
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 11:28:35 (permalink)
    0
    8-bits on both.  It's not the baudrate becuase the PIC transmit is working properly to the PC.  
    It's unclear to me how to set the number of stop bits on the PIC.  I believe that 1-stop bit is the only option.  But as I mentioned before, I've changed it on the PC (1,1.5,2) with no different results.   I also mentioned previously I looked at the data being transmitted from the PC to the PIC with a logic analyzer and it is properly timed. 
     
    "Start there"?   I've already dug through most of these details. "U" is a special case because of the 0x55 pattern.
    This is something weird and I was just asking is someone had seen something like this previously.
    I believe it has to do with the low-voltage program mode on this Curiosity board and I'll have to change that to verify that it is the cause of the problem.
     
     
    #7
    crosland
    Super Member
    • Total Posts : 1936
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 11:49:29 (permalink)
    0
    PointOnePA
    It's not the baudrate because the PIC transmit is working properly to the PC.

     
    It could be the baud rate error. Unless bot the PIC and the PC use one of the "magic" crystal frequencies, there WILL be a mismatch in the baud rates. If that's so then all it shows is that the USB converter is more tolerant than the PIC. Having said that, 9615 should be close enough.
     
    Have you looked at the signal quality on Rx and Tx?
     
    Do you have a common ground between the USB converter and the PIC?
     
    What's the PIC Vdd? What levels is the USB converter expecting and driving?
    #8
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/07 12:04:19 (permalink)
    0
    It's not a baud rate error.  Transmit from the PIC to the PC works and I've verified that the data from the PC to the PIC is properly clocked/timed.  The PIC receive baud rate will NOT be different from the PIC transmit frequency.
     
    The signal quality is fine. Not a noise issued. Verified with scope.  It's a pristine setup; short lines;common ground shared between serial DB9 on PC to Pic board.  The PIC received data is repeatable, incorrect, but repeatable.   The PIC is powered by a USB connection, 5V.  The serial USB is a 5V level TTL serial device which I've used before on NxP/Freescale and PIC 5V devices.
     
    ....  I'll try high voltage programming to see if that resolve the problem.  
    Thanks for all the comments.
     
    #9
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 08:31:46 (permalink)
    0
    I finally figured out my problem. I forgot about the RS232 to TTL inversion issue. 
     
    The PIC16F15323 that I'm using allows you to configure the polarity of the outgoing Transmit signal, but you are stuck with the polarity of the incoming signal on the RX pin.  Normally I'd have a MAX323 line driver to do the signal inversion, but I forgot about that and I was just trying to go directly to the TX pin from the PC RS232 DE9 connector to the PIC's RX pin.   To test/resolve the issue, I put a NOT/inverter on this signal using a 2N3904 (NPN), and then I could properly echo my transmission to the PIC (while still configuring the PIC TX polarity).
     
    I should have included a wiring diagram with the original question, then you could have pointed out my error.
    Sorry for the confusing question, but problem resolved.
     
    post edited by PointOnePA - 2020/04/08 08:35:26

    Attached Image(s)

    #10
    crosland
    Super Member
    • Total Posts : 1936
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 09:14:16 (permalink)
    +2 (2)
    SO when you said 
    PointOnePA
    I've set it up for 9600N81 and it correctly transmits data to a PC using a TTL_RS232 to USB converter.  

     
    You weren't telling the whole truth.

    PointOnePA
    I finally figured out my problem. I forgot about the RS232 to TTL inversion issue.

     
    There isn't one when connecting a TTL converter to a PIC. That's probably why no one said anything.
     
    trying to go directly to the TX pin from the PC RS232 DE9 connector to the PIC's RX pin.

     
    Why on earth, when you had a USB converter?.
     
    I should have included a wiring diagram with the original question, then you could have pointed out my error.
    Sorry for the confusing question, but problem resolved.
     



    <sigh>
    #11
    Beau Schwabe
    Starting Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2019/09/23 21:16:53
    • Location: 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 09:27:42 (permalink)
    0
    If you have a spare pin you can use the Interrupt On Change(IOC) feature on that pin so that an interrupt is triggered on both a rising and falling edge.  This pin would be your 'new' RX input.
     
    PreSetup: instead of configuring your previous RX pin as an INPUT make it an OUTPUT instead and pre set it so that it is HIGH.  I know this seems counter intuitive and against what the UART receive setup describes, but I have done this sort of thing before when the UART wasn't available on a certain port and it works just fine.  9600 baud should be no problem.
     
    Inside of the interrupt the first thing you check is if the interrupt came from the IOC if so then clear the IOC flag and check the state of the spare input pin and reflect the opposite state on the previous RX (now an output). Now exit the interrupt... by making the pin change, an additional interrupt will be generated, this time for the UART.  Allow that to proceed as normal through the interrupt routine. 
    post edited by Beau Schwabe - 2020/04/08 10:06:26
    #12
    NKurzman
    A Guy on the Net
    • Total Posts : 18655
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 10:10:38 (permalink)
    +1 (1)
    "correctly transmits data to a PC using a TTL_RS232 to USB converter"
    Is it not receiving with the same convertor?  The FTDI and MCP2200 both present the signals correctly.
    #13
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 10:19:52 (permalink)
    0
    Problem resolved.
    #14
    NKurzman
    A Guy on the Net
    • Total Posts : 18655
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 10:52:44 (permalink)
    +1 (1)
    The Point is Not Just to resolve your Problem, But to leave enough information for others with the same problem to be able search for the answer in the Old Posts.
    #15
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 10:58:51 (permalink)
    +1 (1)
    Which has been done.
    #16
    Jerry Messina
    Super Member
    • Total Posts : 502
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 11:36:18 (permalink)
    +1 (1)
    and I was just trying to go directly to the TX pin from the PC RS232 DE9 connector to the PIC's RX pin.   To test/resolve the issue,

    "And to not blow up my pic because of the large +/- voltage present on the TX pin of the RS232 signal..."
     
    #17
    NKurzman
    A Guy on the Net
    • Total Posts : 18655
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 12:05:50 (permalink)
    0
    Jerry Messina
    and I was just trying to go directly to the TX pin from the PC RS232 DE9 connector to the PIC's RX pin.   To test/resolve the issue,

    "And to not blow up my pic because of the large +/- voltage present on the TX pin of the RS232 signal..."



    Oh, I missed that.  Strange setup. Buffered one way, but not the other.
    #18
    PointOnePA
    New Member
    • Total Posts : 15
    • Reward points : 0
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 12:16:23 (permalink)
    0
    The USB to serial device has a DE9 connection and is a 5V logic level, similar to the FTDIchip USB-to-RS232 cables.
     
    To add to the body of knowledge, you might state that if ASCII "U" 0x55 is being received accurately, but if numerical "1" is being received as hex 0x67 and not 0x31, then that's a clear indication of a polarity issue, since 0x55 looks the same either way, (and thus the baud rate is correct), but 0x31 inverted looks like 0x67.
     
     
    #19
    Jerry Messina
    Super Member
    • Total Posts : 502
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: PIC16F15323 EUSART Async RX timing (framing error) 2020/04/08 13:17:24 (permalink)
    +1 (1)
    You're the one who was talking about RS232.
     
    If it's a USB-TTL UART converter then as Nkurzman said, it should have the proper polarity out of it already. All of the FTDI cables do... TXD/RXD idle high. It's a weird cable if it inverts them. That would make it next to useless in a lot of applications since you'd have to invert everything to connect it to a normal UART (imho).
    #20
    Jump to:
    © 2020 APG vNext Commercial Version 4.5