• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 1778 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.

TM4C123GH6PM: UART first time read wrong value

Djedjica
Intellectual 860 points
Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: PROFIBUS

Hello everyone, 

I have an issue with UART communication. I connected two tiva boards for UART serial communication (to simulate operation of custom electronics that I wait to be made). It is simple communication in which one board sends another board 1 byte of data twice (2 bytes), just to confirm the validity of data arrived. 2 bytes are sent on button click. I configured receiver board UART to interrupt on 2 bytes received, and that seems to work fine. Problem is that first time receive, system interrupts when the first byte is received and reads received byte and one byte of zeros. Each next receive is now shifted for me, since board reads remaining byte of previous msg and one byte of new msg. I tried reading data in FIFO in configuration function but seems that this does not work. How can I handle this, how can I make sure there is nothing in FIFO when system starts? Below is the code for receiver board UART. 

        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);
	GPIOPinConfigure(GPIO_PC4_U1RX);
	GPIOPinConfigure(GPIO_PC5_U1TX);
	ROM_GPIOPinTypeUART(GPIO_PORTC_BASE, GPIO_PIN_4 | GPIO_PIN_5);
	ROM_UARTConfigSetExpClk(UART1_BASE, ROM_SysCtlClockGet(), 115200,(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE ));
	ROM_IntEnable(INT_UART1);
	ROM_UARTIntEnable(UART1_BASE, UART_INT_RX);

	UARTFIFODisable(UART1_BASE);
	UARTFIFOEnable(UART1_BASE);
	UARTFIFOLevelSet(UART1_BASE, UART_FIFO_TX1_8, UART_FIFO_RX1_8);
	uint32_t dummy=0;
	while(UARTCharsAvail(UART1_BASE))
		dummy = UARTCharGet(UART1_BASE);

  • 0
    Guru 27665 points

    Djedjica said:
    , how can I make sure there is nothing in FIFO when system starts?

    By reading it until it is empty?

    BTW if you are depending on just reading two bytes and always keeping them in order, that will inevitably fail. You need some sort of synchronization mechanism.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Greetings Robert,

    Similar came up w/us - may we ask if, "CR/LF" (or another "rare" char.) may serve as serial termination - affording adequate "sync" - in your opinion?     Merci...

  • 0 in reply to Robert Adsett
    Intellectual 860 points
    Yes, I also had that in mind, that is why I have that dummy read in UART configuration but that seems to not work since I still get that empty byte on first interrupt. So setting UART to interrupt on some FIFO level (In my case 2 bytes) is not sufficient but I also need to add some synchronization mechanism?
  • 0 in reply to cb1_mobile
    Guru 27665 points
    Sure, even just CR or just LF would work as long as the character doesn't show up in normal data. As long as you've got something that indicates the start of information you can re-sync. You can make it more complex and robust (checksums, packet length fields, end of packet indicators) and for binary data that approaches being necessary. For ASCII though a CR/LF would work and, of course, displays nicely.

    Robert

    And Modbus shows even timing can be used.
  • 0 in reply to Djedjica
    Guru 27665 points

    Djedjica said:
    So setting UART to interrupt on some FIFO level (In my case 2 bytes) is not sufficient but I also need to add some synchronization mechanism?

    Think about what happens when extra characters are inserted (or characters are deleted) due to corruption. What happens if one side is transmitting while the other is setting up. Watchdog? Power sag? Someone wraps the cable around a fluorescent ballast**.

    Also remember that 2 byte FIFO interrupt does not mean there are two bytes in the FIFO it means one of the following:

    • Two bytes in the FIFO
    • More than two bytes in the FIFO
    • One byte in the FIFO and the receive timeout has passed*

    Robert

    * For reasonable implementations. TI is peculiar in separating the RTI from the RI. Reasonable implementations will treat these identically.

    ** I hear the original Ethernet manuals contained explicit warnings about wiring Ethernet cable (either the then thick Ethernet coax or drops) next to either ballasts or linear accelerators.

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert - Merci - as many of our designs exploit our display capability - CR/LF prove ideal - thank you for confirming our choice.   (somehow - I'm "Unable to "LIKE!")

    And - your direction, "Don't re-invent Modbus - if you need to use it" proves SO true, SO time & effort saving - Bravo!      Perhaps even "generalizing" ... the "proper search for - and then "attachment to" - an "existing standard" (rather than "inventing a new/fresh one")  - rises to "always, should be considered!"

  • 0 in reply to Robert Adsett
    Intellectual 860 points
    Yes, my mistake for not thinking for those situations. I need to go and read about modbus to see on how to implement it for this mcu. I am afraid using CR/LF is not good solution for my system since any combination of bits within byte is equaly possible.
    Using simply RI is not reliable enough? Or I can maybe use that if I fail in modbus implementation for this device?
  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert Adsett said:
    ... explicit warnings about wiring Ethernet cable ... next to either ballasts or linear accelerators.

    This is NOT considered acceptable?     And (only) "NOW" you tell us!       (Ratz - the many & secure "attachment points" - afforded by that Fermi Lab "labyrinth structure" - were exploited by "crack" (warning unaware) staff...)

  • 0 in reply to Djedjica
    Guru 27665 points

    Djedjica said:
    Using simply RI is not reliable enough?

    Receive interrupts only wouldn't give you any way of determining when the information started.

    Djedjica said:
    Or I can maybe use that if I fail in modbus implementation for this device?

    There's a lot of serial communication protocols available*. If you don't need a lot of bandwidth I'd suggest starting with Modbus/ASCII. It's quite simple w/o much in the way of timing constraints, I've done a master in an interpreter w/o much problem.

    If you need a lot of small packets relatively frequently, I'd suggest using CAN. It takes care of all the packet details so you can concentrate on the higher level interface/protocol. You do have to guard against delta values and it takes a little more effort to get working but it has a lot of features built-in to make it more robust.

    Robert

    * Let's see how many we can name. There must be a list somewhere. Off the top of my head Modbus/RTU, Modbus/ASCII, DMX, RDM, MDB (which I just heard of), Profibus (I think)

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    And (only) "NOW" you tell us!  

    And don't forget you must take great care when drilling a hole into the bus cable for tapping.

    Robert