• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 513 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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] UART4 Rx pin (PC4) doesn't seem to capture data properly

e2e_gai
Prodigy 40 points

Hello,

I have a sensor that sends data to the microcontroller via UART with the following specifications:

Baud Rate: 9600

Data Bits: 8

Parity: None

Stop Bits: 1

Flow Control: None

Voltage: 3V

Below are some snippets of my code (I apologize for the lack of comments)

SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN); // PLL (400MHz) / 2 / 2.5 (SYSDIV) = 80 MHz system clock speed
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC); // enable GPIO Port C peripheral
SysCtlPeripheralEnable(SYSCTL_PERIPH_UART4); // enable UART4 peripheral
GPIOPinTypeUART(GPIO_PORTC_BASE, GPIO_PIN_4 | GPIO_PIN_5); // assign pin types in Port C as UART
GPIOPinConfigure(GPIO_PC4_U4RX);
GPIOPinConfigure(GPIO_PC5_U4TX);
UARTConfigSetExpClk(UART4_BASE,SysCtlClockGet(),9600, UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE);
UARTFIFOEnable(UART4_BASE);
UARTIntRegister(UART4_BASE,UART_Handler);
UARTIntEnable(UART4_BASE,UART_INT_RX);
UARTEnable(UART4_BASE);
void UART_Handler(void) {
	UARTIntClear(UART4_BASE,UART_INT_RX);
	int i = 0;
	char uartrecv;
	do
	{

	// Read a character using the blocking read function.  This function
	// will not return until a character is available.

	uartrecv = UARTCharGet(UART4_BASE);
	UART_buffer[i] = uartrecv;
	i++;



	//
	// Stay in the loop until either a CR or LF or i<10 is received.
	//
	} while((uartrecv != '\n') && (uartrecv != '\r') && (i<32));
}

The problem is that the UART_buffer has a bunch of random characters. As well, when I look into the register, the frame error bit goes high once in a while...

I'm not really sure what I'm doing since I'm new to using UART.


Thanks in advance!

  • 0
    TI__Guru**** 244380 points
    Hello e2e_gai,

    The function SysCtlClockGet() has a problem in 2.1.0-12573 release of TivaWare. Since you are using 80MHz, it will return 66MHz causing the issue. Instead if you use 80000000 in place of the function, it should work fine.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points

    Amit Ashara said:
    Instead if you use 80000000 in place of the function, it should work fine.  

    Amit's diagnosed this (long ongoing) issue well.  (herd of "speeding" turtles passing vendor's API rewrite crue - on the right...)

    Yet - suspect that you'd be better served to specially highlight the fact that, "Any other use of "SysCtlClockGet()" anywhere else w/in your program - will be so plagued.   Suggest that you emblazon "SysCtlClockGet()" at very top of your program - and then - prior to your new code download you employ "Find and Replace" to insure that NO errant "SysCtlClockGet()" entries (which appear SO often w/in APIs) wreak their (unwanted) magic...

    Function devoted to "User Convenience" instead wreaks havoc.   (API giveth - and (sometimes) API taketh away...)

  • 0 in reply to Amit Ashara
    Guru 92251 points

    Amit Ashara said:
    The function SysCtlClockGet() has a problem in 2.1.0-12573 release of TivaWare.

    Another work-around is to use the ROM_SysCtlClockGet() function, since the ROM version operates correctly.

  • 0 in reply to Chester Gillon
    Guru 117855 points

    Chester Gillon said:
    Another work-around is to use the ROM_SysCtlClockGet() function, since the ROM version operates correctly.

    Should such prove true - across a variety of vendor's MCUs - both vendor's and my "work-around" decline greatly...

    That said - as the API (so often) includes the Non-ROM version of that errant function (w/in multiple/other functions) - my suggestion of, "Find & Replace" very much stands as a much required, "Safety!"  In fact - w/in earlier "StellarisWare" driverlib "9453" - 12 files are listed during a search for, "SysCtlClockGet()!"  (most being serial comm related - thus their "tie in" to system clock.)   Thus - the suggested, "Find & Replace" appears a most valid recommendation...

    Point remains - "fix" quickly/initially (vendor offered) was "one-time, one-event" - yet this function is devious - likely appears multiple times w/in "average program" (while hiding) and is guaranteed to "catch/trap the unwary!"