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 RXFE (Receive FIFO Empty) bit of UART Flag Register shows as 1 even on reception of Serial Data with FIFO disabled

Part Number: TM4C123GH6PM


Greetings ! I am thankful for this community Forum.

Issue - Behavior of RXFE bit of UART Flag Register when FIFO is disabled

Scenario - UART0 is used with FIFO disabled. A byte of data is sent using a terminal application running on PC to the Tiva Board over UART. I see that the RXFE (Receive FIFO Empty) bit of 

the UART FR(Flag Register) is 1 even on reception of the 1 byte data sent via terminal application; thus I am unable to read using UARTCharGetNonBlocking(). The datasheet says -

If the FIFOs are disabled, the empty and full flags are set according to the status of the 1-byte-deep holding registers.

Thus, I am expecting this Flag bit to be 0 once the data is received. 

Also, As the datasheet mentions -

Both FIFOs are accessed via the UART Data (UARTDR) register.

I am able to access the byte received by directly reading the UART data register instead.

I have 2 questions here -

1. Why RXFE indicates that the UART Receive holding register is EMPTY even when I am able to read the received byte by directly accessing the UART data register ?

2. The datasheet mentions the following about the UART Data Register -

Important: This register is read-sensitive.

What does read sensitive means here ?

/*** main.c ***/

#include <stdint.h>
#include <stdbool.h>
#include <cmsis_os.h>
#include "driverlib/sysctl.h"
#include "driverlib/rom.h"
#include "UART_handler.h"

void controllerInit();

int main()
{
	controllerInit();
	UART0_init();
	while(1);
}

void controllerInit()
{
	// Set the controller Clock
	ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);
}
/*** UART_handler.c ***/

#include "UART_handler.h"

// UART0 Interrupt Service Routine
void UART0_ISR()
{
	volatile uint32_t ui32Status, ui32ReceivedData=0;
	volatile uint8_t ui8RxData = 0;
	ui32Status = ROM_UARTIntStatus(UART0_BASE, true);
	UARTIntClear(UART0_BASE,ui32Status);
	switch(ui32Status)
	{
		case UART_INT_RX:
			{
				if(UARTCharsAvail(UART0_BASE))
					ui8RxData = UARTCharGetNonBlocking(UART0_BASE);
				else
				  ui8RxData = UART0->DR;
			}
			break;
	}
}

void UART0_init()
{
	// UART Peripheral Enable
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
	// GPIO enable which contains UART pins
	ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
	// Master interrupt enable
	ROM_IntMasterEnable();
	// COnfigure UART Rx pin
	GPIOPinConfigure(GPIO_PA0_U0RX);
	// COnfigure UART Tx pin
	GPIOPinConfigure(GPIO_PA1_U0TX);
	// Configure UART pins
	ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
	// Configure UART clock
	ROM_UARTConfigSetExpClk(UART0_BASE, ROM_SysCtlClockGet(), 115200,
													(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
													 UART_CONFIG_PAR_NONE));
	// Disable the FIFO
	UARTFIFODisable(UART0_BASE);
	// Enable UART interrupt
	ROM_IntEnable(INT_UART0);
	// Enable UART Rx interrupt
	ROM_UARTIntEnable(UART0_BASE, UART_INT_RX);
}
/*** UART_handler.h ***/

#ifndef __UART_HANDLER__
#define __UART_HANDLER__

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "driverlib/debug.h"
#include "driverlib/fpu.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/pin_map.h"
#include "driverlib/rom.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"
#include "TM4C123GH6PM.h"

void UART0_init();

#endif

 

 


  • Saurabh Soni said:
    What does read sensitive means here ?

    By "read sensitive" - you are alerted - that the simple, "Act of reading" (such "read-sensitive declared" Register) is likely (even expected) to cause, "Alteration to that Register's Content!"

    I suspect that your issue (may) result due to,  "Key (i.e. sensitive) UART Registers" being,  "Open for view" w/in your IDE.     That "being open for view" likely causes an (unwanted) alteration of your "key bit" - which would be "Altered by the simple act of such critical a Register being "addressed & read."     (even by your IDE - prior to your "official code read.")

    You may check/confirm via, "Removing that key Register" - from "Open to View" status (via the IDE) - and then repeating your examination...    Bon chance.

    BTW - simply terrific posting - well described - neatly presented - and highly detailed!     Excellent!     And ... your very first posting!     Far, far beyond my 1st posting - in which I (thoughtfully & loudly) proclaimed,  "Does NOT Work!"

    [edit] (added) ...  Here's an import of the  "RXFE"  bit's description w/in Register UARTFR:    (a true copy from MCU manual)

    The meaning of this bit depends on the state of the FEN bit in the UARTLCRH register.

    Value Description

    0         The receiver is not empty.

    1         If the FIFO is disabled (FEN is 0), the receive holding register is empty.    ***  this IS your case (FIFO disabled)

               If the FIFO is enabled (FEN is 1), the receive FIFO is empty.

    And you write:  "I am expecting this Flag bit to be 0 once the data is received."    I am in agreement.

    For now - may I suggest that you, "Check bit "RXFE" w/in UARTFR - prior to sending that single character?    Does the bit, "change state?"     It DOES appear "wise" for you to check & confirm - that bit "FEN" w/in UARTLCRH Register - agrees w/ what's listed, here...

  • Presented below is the MCU Manual's detail re: UARTDR Register - promising "read sensitive" detail - yet (to my view) - "failing to deliver!

    It was expected that a, "R>C"  (any read would clear - or similar) - placed at the appropriate register bit(s) - would confirm such,  "Read Sensitivity."

  • I have been able to duplicate the behavior you mention with FEN. I don't have a good answer for you. Since you are using interrupts, can you just ignore FEN for now while I look into this more?
  • As this was our poster's "VERY FIRST POST" - we should note that your response (properly) targeted HIM.
    My attempt here was to (save) time/effort on your/others' part - by presenting key manual extracts - and "integrating & bunching - MANY key facts" - w/in one posting.   (my 1st one, here)

    Might you comment re: "Proclamation of  "Read Sensitive?"     I've explained to best of my knowledge - yet the Register Description was noted as, "Abandoning its promise..."

    As always - your effort is thanked & appreciated.      WHAT a post by a "First Timer!"

  • Hi CB1,
    Yes your comment about the "Read Sensitivity" is valid. I will make a note to improve that. The point of "Read Sensitivity" is that the read has side effects. The effects of the read are different in FIFO mode and non FIFO mode. In FIFO mode, a read pops the oldest entry out of the FIFO. In non-FIFO mode a read clears the RX interrupt status bits.
  • Thank you, Bob.

    I appreciate that your (wording) "Side Effects" - trumps mine, "Alteration of (that) Register's content."     While mine may be "correct" in this specific instance - yours is a "safer & more general" description.

    While remote - is it possible that (both) poster & (even) you - might have been, "caught by the IDE's ability to  "impact that bit value" - even though unwanted - due to that Register's simply being, "Open/Viewed" AND "Read Sensitive?"     (Note that I detailed such - w/in my initial response here...)

    Again thank you...

  • Firstly, Thank you Sir for your time.

    cb1_mobile said:
    For now - may I suggest that you, "Check bit "RXFE" w/in UARTFR - prior to sending that single character?    Does the bit, "change state?"     It DOES appear "wise" for you to check & confirm - that bit "FEN" w/in UARTLCRH Register - agrees w/ what's listed, here...

    I have verified -

    • Before Sending the first serial byte - 

    1.  Bit FEN w/in UARTLCRH  = 0
    2.  Bit RXFE w/in UARTFR = 1 

    The same state is observed AFTER sending the first serial byte also for both the above mentioned bits.

    cb1_mobile said:
    I suspect that your issue (may) result due to,  "Key (i.e. sensitive) UART Registers" being,  "Open for view" w/in your IDE.

    And Yes, this was the issue ! I am using Keil MDK uVision v5.23. I had UART0 window opened while debugging. [Peripherals -> System Viewer -> UART0 ]

    Below is the snapshot of the same.

    As I tried again - AFTER closing this UART0 window before running the code in debugging mode - I see the code is able to reach Line 17 of UART_handler.c File i.e. I am able to read  using UARTCharGetNonBlocking() !

    cb1_mobile said:
    By "read sensitive" - you are alerted - that the simple, "Act of reading" (such "read-sensitive declared" Register) is likely (even expected) to cause, "Alteration to that Register's Content!"

    I got the idea here - Thank You. 

    cb1_mobile said:
    BTW - simply terrific posting - well described - neatly presented - and highly detailed!     Excellent!

    Thank You for the appreciation :)

  •    

    Bob Crosby said:
    The effects of the read are different in FIFO mode and non FIFO mode. In FIFO mode, a read pops the oldest entry out of the FIFO. In non-FIFO mode a read clears the RX interrupt status bits.
      Thank You Sir for this information. This is helpful.

  • cb1_mobile said:
    It was expected that a, "R>C"  (any read would clear - or similar) - placed at the appropriate register bit(s) - would confirm such,  "Read Sensitivity."

    Is there a way, we can we get these missed Details, Sir ?

  • First - and again - your organization & penchant for detail - especially for "so new" a forum visitor - is (and remains) "OFF the CHARTS GOOD!"     Thank you for your kind verification - so that my pending "departure" from this (LIKE-less) "vale of tears"  - may have mile-stoned.    (maybe)

    Owning & running a small tech firm (after past co-founding - taking another one Public) - I "Have to Ask" - "By what means have you become so (incredibly) Forum Savvy?"     Really - your care, effort & expertise "JUMPS OUT" - I cannot complement you sufficiently!     Who else would "even think" - to "Thank the Forum" - as you did - w/in your "opening post?"      (you may note that (likely) few here will exhibit such curiosity - yet you/I may be, "kindred spirits.")     And your talent & expertise ...  simply demands applause.

    Am I wrong to suspect that you are "rather highly experienced" - and "new" ... (ONLY) to "this vendor" - and/or "this forum?"    (even if so - your postings remain "excellent.")

    To your "missed details" - I've identified that fact - notified the vendor - their reaction is "beyond our control."     Nothing "stops you/others" from, "Editing the MCU Manual" (via color highlights) - directing attention to that Register's "Read Sensitivity."      (Pardon - but waiting for vendor correction - even the (tallest) "sand clock/timer" - may be over-taxed...)

    Did I note that your skill in posting is "terrific?"