• State Resolved
  • Locked Locked
  • Replies 26 replies
  • Subscribers 34 subscribers
  • Views 10044 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Getting a frame error in UART

Xbee
Prodigy 230 points


Basically I am receiving NMEA sentences using  TM4C123G UART pins. sent through an arduino. I am getting a frame error in this sentence:


$GPRMC,143,A,4308,N,77,W,040,183,241007,11.1,W,N*05\r\n"; //GPS

the frame error occurs when I connect the pin in the middle of the operation. as soon as I press the reset button on the arduino it synchronizes and data is correctly received. baud rate is 4800. i am not receiving any error on other nmea sentences. 

what could be the potential problem?

thanks

  • 0
    Guru 11940 points

    I am receiving NMEA sentences using  TM4C123G UART pins ...

    ... the frame error occurs ...

    Can you explain what you mean with "frame error" in this context ?

    NMEA (over serial interface) is just a stream of characters, with no underlying protocol that has "frames" (like ethernet protocols).

    If it's about synchronising reception to sentences, you might need to refine your reception routine (interrupt handler ?).

    Try to provide more relevant information about your issue, to avoid confusion and guessing ...

  • 0
    TI__Guru**** 244400 points

    Hello AM95,

    AM95 said:
    when I connect the pin in the middle of the operation

    Isn't this bound to corrupt the message?

  • 0 in reply to f. m.
    Prodigy 230 points
    frame error as in like baud rate mismatch. the frame error flag gets checked when I go to peripherals->uart in keil uvision. as a result I get garbage data. but when i press reset on the arduino i start getting the desired data.
    can you point as to what to improve in the interrupt handler?
  • 0 in reply to Amit Ashara
    Prodigy 230 points
    it doesn't get corrupt in other nmea sentences when I send sentences such as this one:
    $HEHDT,080.5,T*22\r\n
    at any point in time when i connect this i recieve the data as desired. although this sentence is small as compared to the one i am having problem with.
  • 0 in reply to Xbee
    TI__Guru**** 244400 points
    Hello AM95

    Please explain what you mean by connect the pin in the middle of the operation?
  • 0
    Guru 47900 points

    AM95 said:
    frame error occurs when I connect the pin in the middle of the operation. as soon as I press the reset button on the arduino it synchronizes and data is correctly received.

    How "normal" is such test when you, "Connect in the middle - as you state?"   And - how do you begin to define the, "middle?"

    Would not a corrective action see you, "Throw out" data reception resulting from such, "middle (whatever that means) connection?"   Only allow data received under more "normal" circumstance & operation.  (this assumes that your communication channel is "Two Way" and that you can "halt" the sender - and cause it to "resend."

    As poster f.m. has mentioned - how sure are you that this error is (really) "Frame?"   How have you arrived at that conclusion?

  • 0 in reply to Amit Ashara
    Prodigy 230 points
    i turn the arduino on. it starts to send data serially. i then connect the pin to the tiva controller. it gives me a frame error.
    if I connect the arduino's tx to the rx of the uart in the tiva and then turn it on. i get the data as required.
    I hope you understand what I am trying to say?
  • 0 in reply to Xbee
    Guru 27665 points

    You can check for frame (and other errors) in the interrupt. You have to enable the appropriate interrupt sources. However...

    You connect in the middle of a transmission, that being the case there is no reason to expect a valid response. In your interrupt, or preferably outside of the interrupt. You need to check the validity of a packet before using it. This is not the only possible source of error, just one you are able to repeat currently.

    Robert

  • 0 in reply to Xbee
    TI__Guru**** 244400 points
    Hello AM95

    I got it. There is no guarantee that any microcontroller will receive the correct data if the pins are connected on the fly.
  • 0 in reply to Amit Ashara
    Prodigy 230 points
    is there any way workaround for this?
  • 0 in reply to Xbee
    Guru 47900 points
    That error seems (very) well deserved!
    In my earlier post I described a "corrective action" method. It is unrealistic for you to expect "error-free" operation when connection is random & arbitrarily initiated...
  • 0 in reply to Xbee
    Guru 11940 points

    You could have told that the framing error flag of the UART register.

    The fact that it happens with the GPRMC sentence is just likelihood, and has nothing to do with the contents of the NMEA sentence.

    Solutions:

    • don't connect/disconnect wires while operating
    • clear the FE flag

    When receiving UART data (or serial data in general) it is recommended to always check for errors, and clear the flag (+ deal with the error) first.

  • 0 in reply to f. m.
    Prodigy 230 points
    thanks for your replies everyone. I get it. Yes I do clear the interrupt sources before reception.
  • 0 in reply to Xbee
    TI__Guru**** 244400 points
    Hello AM95,

    The only workaround is a handshake using GPIO. The Slave board sets a GPIO high which the TM4C board samples and then makes another GPIO high which the slave board samples. This procedure can be repeated N times to establish that the two boards are connected.
  • 0 in reply to Xbee
    Guru 11940 points
    Probably not all flags.
    Frame error means, the UART did not recognize the last character. This happens in your case when you connect the wires in the middle of a character "frame".
    Some flags are cleared with reading the RX registers, others not. Check the datasheet - I can't recall all this register/flag details from memory ...
  • 0 in reply to f. m.
    Guru 27665 points
    Also this only deals with the question of bit errors within a character (and not all of them). More generally if you can validate the packet then detecting the character errors is redundant.

    You have a checksum, and packet (sentence) delimiters. So you should be able to do a lot of validation even without considering the content details.

    Robert
  • 0 in reply to Robert Adsett
    Guru 11940 points

    I avoided bothering the O.P. with semantic issues of the next higher level.

    Also this only deals with the question of bit errors within a character (and not all of them).

    Would need to re-read the datasheet, but do certain error conditions not keep the hardware (UART) keeping from receiving further characters until cleared ?

    And upon a single character reception error, one can usually discard the whole GPS sentence (up to the next "\r\n").

  • 0 in reply to f. m.
    Guru 27665 points

    f. m. said:

    I avoided bothering the O.P. with semantic issues of the next higher level.

    Also this only deals with the question of bit errors within a character (and not all of them).

    Would need to re-read the datasheet, but do certain error conditions not keep the hardware (UART) keeping from receiving further characters until cleared ?

    Pretty sure they don't. I haven't run across a UART that does that although I do recall ones that had sticky faults. Not that I've seen all possible UARTs mind you.These UARTS though have 12 (I think 12) bit wide FIFOs the upper 4 bits are to keep per character fault flags.

    f. m. said:
    And upon a single character reception error, one can usually discard the whole GPS sentence (up to the next "\r\n").

    True, but packet level detection detects as many or more faults w/o burdening the interrupt. And the packet level detection must be done in any case since so many errors will escape detection at the character level.

    If you can keep the interrupt to packet framing (or less) it simplifies it considerably.

    f. m. said:
    And upon a single character reception error, one can usually discard the whole GPS sentence (up to the next "\r\n").

    True but you do still have to read them, if only to find the end of/start of packet.

    Robert

  • 0 in reply to Robert Adsett
    Guru 11940 points

    Pretty sure they don't. I haven't run across a UART that does that although I do recall ones that had sticky faults. Not that I've seen all possible UARTs mind you.These UARTS though have 12 (I think 12) bit wide FIFOs the upper 4 bits are to keep per character fault flags.

    I had another vendor's UART implementation in mind I messed with recently. Pretty sure it behaves this way. (And this UART has no FIFO, since this vendor solely relies on DMA).

    True, but packet level detection detects as many or more faults w/o burdening the interrupt. And the packet level detection must be done in any case since so many errors will escape detection at the character level.

    I use to do it in the interrupt, though.

    Upon a start character ($) I reset the index. For receive errors (like that) I just set the index out-of-range (index is checked before any char storage). And when encountering the end sequence (while the index is valid), I pass the received string on to a parsing/processing routine - not done in interrupt context.

    This way, I consider only sentences which are ostensibly valid (having correct start and stop, and a reasonable length), without loading the interrupt routine too much.

    However, there are many ways to skin a cat ...

  • 0 in reply to f. m.
    Guru 27665 points

    f. m. said:
    However, there are many ways to skin a cat ...

    And a few naked cats we haven't mentioned.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    And a few naked cats we haven't mentioned.

    And - to be complete - NO Cats - (skinned, unskinned, clothed or naked) were harmed - during the response to this thread...

  • 0 in reply to cb1
    Guru 11940 points

    ... NO Cats  .. were harmed ...

    Perhaps on your side  - just returned home and stuffed my Kaya KTB back into the sleeve ... ;-)

  • 0 in reply to f. m.
    Guru 47900 points
    Crack staff (this side) have alerted the authorities...
  • 0 in reply to cb1
    Guru 11940 points

    Thanks for the hint - hiding all evidence ...

  • 0 in reply to f. m.
    Guru 47900 points
    You may wish to remove your server from its (pristine) bathroom location - and pay (some/slight) attention to "sensitive" documents - in addition to "evidence destruction/hiding/dismissal" while stuffing (soon to be banned) objects into their sleeve... (so I'm told - I'm simple reporter...)
  • 0 in reply to cb1
    Guru 11940 points

    Just thought about the (dead) cat, which is now processed entirely - and thus proved to be useful at least once ... ;-)