EK-TM4C123GXL: UART on TM4C123: Not able to read from Receive FIFO

Suyash Bagad said:

Even a small help would be appreciated in this direction.

And indeed - such "small help" is my specialty.      BTW - very excellent post - well formatted & clearly presented.     And - just noted - this is your "Very First Post" - outstanding!

Here several questions/comments:  (and naked opinion)

• How do you know that you are transmitting successfully?      (that's not explained - it is dangerous for we remote from you to "assume" - have you scoped the TX output?
• Minus the usual UART "line driver" - it may prove useful (even necessary) to add a pull-up resistor to the UART's TX pin.      Recall that any "attached" RX pin awaits the "change in signal level" to mark the arrival of the key "Start Bit."    Unless UART TX "defaults to data out High" - I'd add that resistor.   (10K should do)
• You enable the UART - but do not "Wait for its becoming ready!"    (via the SysCtlPeripheralReady() function.)       "Not waiting" (may) work sometimes (even often) - yet is NOT guaranteed!
• You've chosen the more complex, "UART_CONFIG_PAR_ZERO" parameter.     While such may be valid - "PAR_NONE" proves far more common - KISS dictates that you, "Start Basic!"
• The code example w/in the "Peripheral Driver Library User's Guide" employs "while" w/in "UARTCharGetNonBlocking()" - which (may) relax the timing required for "unpacking the UART FIFO."     (maybe)    Your use of the "if" may prove suspect...
• As always - I'd probe (cautiously, of course) as close to the "Failing RX pin" as possible - to insure that the TX signal (really) IS Arriving.

Again - yours is a strong candidate for "best ever" FIRST TIME POST!     GREAT JOB!    (and SO Deserves a "LIKE" - yet that AWARD has been deleted - and for NO GOOD/SOUND Reason!)

I can offer a little bit of help. The second argument to the function UARTConfigSetExpClk, which you call in setting up both UART1 and UART2,  is the clock rate, not the clock source number. It should look like this:

    UARTConfigSetExpClk(UART2_BASE, 16000000 ,9600,UART_CONFIG_PAR_ZERO);

That should get your baud rate to 9600.

Your code is sending 16 characters on UART1, one at a time with a 1 second delay between each character. Then you read one character from the FIFO on UART2, delay 2 seconds, the repeat sending 16 characters on UART1. Is that what you intended to do? The FIFO on UART2 will overflow the second time through the loop.

OK, two more suggestions. First, you did not set the character length. By default it is only 5 bits. If talking to a GPS you probably want something like this:

    UARTConfigSetExpClk(UART2_BASE, 16000000 ,9600, (UART_CONFIG_WLEN_8 |UART_CONFIG_STOP_ONE|UART_CONFIG_PAR_NONE));

Next, you must enable both the pin port and the UART before setting the pin type to UART.

    // Enable GPIO port D which is used for UART2 pins.
    // TODO: change this to whichever GPIO port you are using.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

    //
    // Enable UART1 so that we can configure the clock.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART2);
    //
    // Configure the pin muxing for UART2 functions on port D6 and D7.
    // This step is not necessary if your part does not support pin muxing.
    // TODO: change this to select the port/pin you are using.
    //
    GPIOPinConfigure(GPIO_PD6_U2RX);
    GPIOPinConfigure(GPIO_PD7_U2TX);

That said, I suggest you look carefully at some of the example code on how the peripherals are initialized. Sometimes simple things like the order of the function calls is important.

When Samuel Clemens (who wrote under the pen name of Mark Twain) was young and was interviewed for a job as a river boat captain, he was asked if he new where all of the sand bars were. He promptly replied "No, but I know where they ain't". Using proven example code is like going where we know the "sand bars ain't".

While Mr. Twain may have "avoided the sandbars" - should not those here recognize that "even example code" sometimes omits (necessary/helpful) function calls?

The example presented (post above) makes no mention of the "useful call" to "Peripheral Ready" - while "not always" required - such "defensive coding" serves to "make sense!"      (avoid sandbars.)

The post above "teases" re: "Pin Type" - yet lists "Pin Configure" - it is assumed that "Pin Type" is to follow "Pin Configure" - may that be considered a "General Rule?"    (Team/I can find no mention of such a rule despite much "combing of the docs.")

Note too - (as mentioned in the early answering post) that the PDL "studiously avoids" most all, "Peripheral Initialization" - inviting posters to a high cliff.      (which does offer a "river view!")

Thanks a lot cb1_mobile and all others for all the suggestions!

You were right on point in suggesting for suspicious Transmission itself. I checked the transmission pin using an oscilloscope to get nothing except a constant 3.5-3.6V (appx). 

Going back to basics, I tried writing a simpler code to test UART transmission. I have configured UART0 and UART2 ports, and I am echoing (with a slight modification) any received character at UART0 again to UART0 (So, if I press 'A' and send from PC to UART0, I see a 'B' on the Serial Monitor on PC). Now, I am also echoing the same character to UART2 port (i.e. Transmitting 'A' from UART2 Tx pin (PD7)), and checking the signal on the same pin (PD7) on oscilloscope, again getting a constant '0' Volts. 

Concluding, The UART0 port is working fine but UART2 (or UART1, I've tried both of them) port isn't. Please help me debug this, I am trying hard since yesterday!

#include <stdbool.h>
#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"

void
ConfigureUART(){

	SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);
 	SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
 	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
 	GPIOPinConfigure(GPIO_PA0_U0RX);
 	GPIOPinConfigure(GPIO_PA1_U0TX);
 	GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
 	UARTConfigSetExpClk(UART0_BASE, SysCtlClockGet(), 115200,
 	(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));


 	SysCtlPeripheralEnable(SYSCTL_PERIPH_UART2);
 	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
 	GPIOPinConfigure(GPIO_PD6_U2RX);
 	GPIOPinConfigure(GPIO_PD7_U2TX);
 	GPIOPinTypeUART(GPIO_PORTD_BASE, GPIO_PIN_6 | GPIO_PIN_7);
 	UARTConfigSetExpClk(UART2_BASE, SysCtlClockGet(), 9600,
 	(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));

}

int main(void) {
 
 	 ConfigureUART();
	 UARTCharPut(UART0_BASE, 'E');
	 UARTCharPut(UART0_BASE, 'n');
	 UARTCharPut(UART0_BASE, 't');
	 UARTCharPut(UART0_BASE, 'e');
	 UARTCharPut(UART0_BASE, 'r');
	 UARTCharPut(UART0_BASE, ' ');
	 UARTCharPut(UART0_BASE, 'T');
	 UARTCharPut(UART0_BASE, 'e');
	 UARTCharPut(UART0_BASE, 'x');
	 UARTCharPut(UART0_BASE, 't');
	 UARTCharPut(UART0_BASE, ':');
	 UARTCharPut(UART0_BASE, ' ');

	 UARTCharPut(UART2_BASE, 'A');

	 while (1)
	 {
	 	if (UARTCharsAvail(UART0_BASE)){
	 		uint32_t recd = 0;
	 		recd = UARTCharGet(UART0_BASE);
	 		UARTCharPut(UART0_BASE, recd+1);
	 		UARTCharPut(UART2_BASE, recd);
	 	}

	 }

}

Greetings Suyash,

You've produced another thoughtful, well formatted & detailed post - again Bravo! (Off the charts good - especially for one "so new" here.)

Another here - likely "missed the fact" that PD7 is a "Devil Pin" - and should be avoided - unless you are prepared to "Shift your attention from your "central task!"        (this is a severe violation of KISS - whatever success firm/I enjoy - most always stems from "KISS directed focus & sustained effort!"       (i.e. we "show up" - and bring "Laser Focus" to the smallest element of, "Task at Hand!)

Kindly "avoid" use of PD7 and PF0 - I'll explain later - AFTER you've resolved your UART issue.     (such deflects from your central task!)

Choose a UART which does not include either "devil pin."

Do note that "only" UART0 "enjoys" level-shifted (to USB) connection to the outside (USB primarily) world.         I believe that you are transferring data, "BETWEEN TWO OF THE MCU'S UARTS" - which avoids this issue - yet may still challenge your ability to "recognize data" at any Non-UART0 Port...

I missed the following earlier - might you further detail?

Suyash Bagad said:

I am echoing any received character at UART0 again to UART0  ...  Now, I am also echoing the same character to UART2 port (i.e. Transmitting 'A' from UART2 Tx pin (PD7))

Do help myself (and others) to understand - which Port & Pin (was) to receive your,  "UART2 TX (PD7) output?"      That level of clarity IS required - yet absent.      And - as I noted earlier "PD7 is a Devil Pin" should be avoided.    (deviates from our critical path!)

By choosing another UART Port (Devil Pin free) we (still) need to know,  "How, What, and Where" you are connecting!      (Do provide - just as you did on your terrific 1st ever post: (i.e. PAx to PBy etc.)     That will prove extremely helpful.     Look again at your quote (in highlight) clearly - we've NO idea of the destination of that transmission!      ("A" is going somewhere!)      That's important - is it not?

Slow,  steady, focused, one small element of your task at a time - is your recommended process.      (and that's just how I took past Tech firm Public)

I wanted to further commend you for "Breaking from the Millennial Code" of  (always & only) responding - "When they have (what they believe to be) a near perfect answer/comment.      Such leaves the "other party" "Swinging in the Wind" - never knowing if you: a) have received our request; b) have NO idea how to respond; c) are hard at work on our request; or d) have given up!      None of those "alternative meanings" work to your favor/advantage - is that not so?      

Far better - "Dear Client - Received and am "hard at work" upon your request.    Will be back to you w/in x number of hours/days/weeks/millennium, etc."     At least that's "something" - we note that you wrote similarly - earlier today - this is provided for (other) millennials - who may "wander upon this thread."

Dear cb1_mobile (1830783) , I apologise for not replying, and yes, I was working to see if yours and others' suggestions work.

So, I tried working with UART1 since pin PD7 seems to be the 'devil'. My ultimate aim is to read data from GPS module (by sending appropriate AT commands to SIM808) and see it on the serial console on computer. The simple code below waits for a character to be read at UART0 Rx port, and if it finds anything (say, character 'A' from computer to launchpad through USB connector), it should echo back a modified version of received character (i.e. 'A' + 1 = 66 = 'B'), and that would be seen on Serial monitor. Also, the character which I send from computer to UART0, same one I am transmitting from the Tx pin of UART1, to send it to the SIM808 module.

Please help me out.

Hardware Connections:

1) Computer to TM4C123GXL by USB cod. (i.e. UART0 on the launchpad by default)

2) Pin PB0 (Rx of UART1 on launchpad) to Tx of SIM808 GSM-GPS module.

3) Pin PB1 (Tx of UART1 on launchpad) to Rx of SIM808 GSM-GPS module.

4) Grounds on both boards shorted.

5) 12K Resistors at the PB0 and PB1 pin ends.

Results on Oscilloscope:

At the Pins PB0 as well as PB1, a constant voltage (appx 3V), but whenever I continuously press some key on keyboard, The voltage level at PB0 as well as PB1 falls impulsively and rises again. I attaching a pic of OScilloscope.

https://drive.google.com/open?id=1xGEgEsP9FkBThQ5hQ_8uyr8knbu6sTQp

:

 Code:

#include <stdbool.h>
#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"

void
ConfigureUART(){

    SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    UARTConfigSetExpClk(UART0_BASE, SysCtlClockGet(), 115200,
    (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));


    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    GPIOPinConfigure(GPIO_PB0_U1RX);
    GPIOPinConfigure(GPIO_PB1_U1TX);
    GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    UARTConfigSetExpClk(UART1_BASE, SysCtlClockGet(), 9600,
    (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));

}

int main(void) {

     ConfigureUART();
     UARTCharPut(UART0_BASE, 'E');
     UARTCharPut(UART0_BASE, 'n');
     UARTCharPut(UART0_BASE, 't');
     UARTCharPut(UART0_BASE, 'e');
     UARTCharPut(UART0_BASE, 'r');
     UARTCharPut(UART0_BASE, ' ');
     UARTCharPut(UART0_BASE, 'T');
     UARTCharPut(UART0_BASE, 'e');
     UARTCharPut(UART0_BASE, 'x');
     UARTCharPut(UART0_BASE, 't');
     UARTCharPut(UART0_BASE, ':');
     UARTCharPut(UART0_BASE, ' ');

     UARTCharPut(UART1_BASE, 'A');
     UARTCharPut(UART1_BASE, 'T');

     while (1)
     {
        if (UARTCharsAvail(UART0_BASE)){
            uint32_t recd = 0;
            recd = UARTCharGet(UART0_BASE);
            UARTCharPut(UART0_BASE, recd+1);
            UARTCharPut(UART1_BASE, recd);
        }

     }

}

Response completed - kindly "humor me" - avoid use of the GSM for now.    (now 03:15 CST US - dog-cat "fight" awoke me - both they & I are now done till "sunrise.")

Do note my listing of  "Devil & otherwise suspect - ports/pins!"      

I've also prepared a list of  (likely)  "SAFE UART Ports" which appear upon LPad headers - making interconnect "quick/easy."      (my kind of interconnect...)

And DO ADD the (forgotten) "Checks for Peripheral Ready"  -  we must be sure to REDUCE (ideally identify & eliminate) "all avenues" of failure...

Good for you - glad that you persisted.

Note that there are (several) "flavors" of "USB to serial" converters.      Such "Serial Converters" may include "USB to RS232" - which is likely to destroy your MCU!      Note my language (earlier) "USB to CMOS" - which best describes an, "MCU friendly - Non-Destructive" USB converter.

Congratulations on your success - thank you for the "resolved" (pays some - not many) bills here (keeps several of our favored  "incandescents" on/glowing)...

It would prove useful to others if you'd describe "which" UART you finally chose - and "What you changed - code wise" - to gain, "Working now status!"

And again - you've authored an "excellent series of posts" - thoughtful & detailed - clearly describing your issue - w/easy to read (i.e. formatted) code - terrific for a new (or even regular) poster...

Excellent - w/in a short time you'll (likely) "be running this forum."       (Yet avoid "complementing others" (as one "SPI challenged" here) objects...)
And your code - did it change (at all) - from your post of earlier this morning?    (12:54, 23 Dec)