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.

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

Part Number: EK-TM4C123GXL

I am having problem receiving characters on the UART port 2 Rx pin. I have connected (hardware) pins PB1 (Tx ox UART1) to PD6 (Rx of UART2). I am transmitting data from the UART1 port succesfully, but unable to receive anything on the UART port 2 Rx pin. I am posting the code too. Even a small help would be appreciated in this direction.

#include <stdbool.h>
#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"
#include "utils/uartstdio.h"
#include "driverlib/interrupt.h"
#include "inc/hw_ints.h"
#include "driverlib/rom_map.h"
#include "utils/uartstdio.h"

//*****************************************************************************


//*****************************************************************************
//
// This function sets up UART1 to be used for communication between launchpad 
// and GPS Module.
//
//*****************************************************************************
void
ConfigureUART1(void)
{

    //
    // Enable GPIO port B which is used for UART1 pins.
    // TODO: change this to whichever GPIO port you are using.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

    //
    // Configure the pin muxing for UART1 functions on port B0 and B1.
    // 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_PB0_U1RX);
    GPIOPinConfigure(GPIO_PB1_U1TX);

    //
    // Enable UART1 so that we can configure the clock.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);

    //
    // Use the internal 16MHz oscillator as the UART clock source.
    // Check with sir
    //
    UARTClockSourceSet(UART1_BASE, UART_CLOCK_PIOSC);

    //
    // Select the alternate (UART) function for these pins.
    // TODO: change this to select the port/pin you are using.
    //
    GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    //
    // Initialize the UART1.
    //
    //UARTStdioConfig(1, 9600, 16000000);

    UARTClockSourceSet(UART1_BASE, UART_CLOCK_PIOSC);

    UARTConfigSetExpClk(UART1_BASE, UART_CLOCK_PIOSC ,9600,UART_CONFIG_PAR_ZERO);

    UARTFIFOEnable(UART1_BASE);

}

//*****************************************************************************
//
// This function sets up UART2 to be used for communication between UART1 and UART2.
//
//*****************************************************************************
void
ConfigureUART2(void)
{

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

    //
    // 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);

    //
    // Enable UART1 so that we can configure the clock.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART2);

    //
    // Use the internal 16MHz oscillator as the UART clock source.
    // Check with sir
    //
    UARTClockSourceSet(UART2_BASE, UART_CLOCK_PIOSC);

    //
    // Select the alternate (UART) function for these pins.
    // TODO: change this to select the port/pin you are using.
    //
    GPIOPinTypeUART(GPIO_PORTD_BASE, GPIO_PIN_6 | GPIO_PIN_7);

    //
    // Initialize the UART1.
    //
    //UARTStdioConfig(1, 9600, 16000000);

    UARTClockSourceSet(UART2_BASE, UART_CLOCK_PIOSC);

    UARTConfigSetExpClk(UART2_BASE, UART_CLOCK_PIOSC ,9600,UART_CONFIG_PAR_ZERO);

    UARTFIFOEnable(UART2_BASE);

}


//*****************************************************************************
//
// This function provides a 1 second delay using a simple polling method.
//
//*****************************************************************************
void
SimpleDelay(void)
{
    //
    // Delay cycles for 1 second
    //
    SysCtlDelay(16000000 / 3);
}

//*****************************************************************************
//
// Send a string to the UART0.
//
//*****************************************************************************
void
UART1Send(const uint8_t *pui8Buffer, uint32_t ui32Count)
{
    //
    // Loop while there are more characters to send.
    //
    while(ui32Count--)
    {

        //
        // Write the next character to the UART.
        //

        while(!UARTSpaceAvail(UART1_BASE)){
            //Wait till space in Tx FIFO is available.
            UARTFIFODisable(UART1_BASE);

            UARTFIFOEnable(UART1_BASE);

        }

        UARTCharPut(UART1_BASE, *pui8Buffer++);

        //
        // Turn on the LED (Green).
        //
        GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_3, GPIO_PIN_3);

        SimpleDelay();

        // Turn off the LED (Green).
        //
        GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_3, 0x00);

        //
        // Turn on the LED (Blue).
        //
        GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, GPIO_PIN_2);

        SimpleDelay();

        //
        // Turn off the LED (Blue).
        //
        GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_2, 0x00);


    }
}

//*****************************************************************************
//
// Configuration for blinking LEDs.
//
//*****************************************************************************
void
ConfigureLED(void){
    //
    // Enable the GPIO port that is used for the on-board LED.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);

    //
    // Check if the peripheral access is enabled.
    //
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOF))
    {
    }

    //
    // Enable the GPIO pin for the LED (PF3, PF2, PF1).  
    // Set the direction as output, and enable the GPIO 
    // pin for digital function.
    //
    GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_3);
    GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_2);
    GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1);

}


//*****************************************************************************
//
// Main Function
//
//***************************************************************************** 

int
main(void)
{

    ConfigureLED();

    ConfigureUART1();

    ConfigureUART2();

    while(true){
        uint32_t rec = 0;

        UART1Send((uint8_t *)"ABCDEFGHIJKLMNOP",16);

        SimpleDelay();

        while(!UARTCharsAvail(UART2_BASE)){
            //
            // Wait till a character is present in the Receive FIFO of UART2.
            //
        }

        //
        // Fetch the character. 'rec' will be true or false depending on the
        // presence of character in the receive FIFO.
        //
        rec = UARTCharGetNonBlocking(UART2_BASE);

        if(rec){

            //
            // Turn on the RED LED.
            //
            GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1, GPIO_PIN_1);

            SimpleDelay();

            //
            // Turn off the RED LED.
            //
            GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1, 0x00);

            SimpleDelay();

        }
    }
}

 

  • 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  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);
    	 	}
    
    	 }
    
    }
    

  • Hello Suyash,
    How are connecting (electrically) your UART1 or UART2 outputs to your terminal?
    Are you aware that the output of the Tiva is not directly compatible with the input expected from PC UARTS?
    Search about TTL and RS232 levels to better understand, as that might be the issue.
    This would not make sense in case you really don't see anything on your PD7, but... are you sure of that? An INACTIVE UART output pin actually stays high, not low as you describe, and your pin configuration is simple and appears to be correct...
    Regards
    Bruno
  • 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...

  • That's most true, cb1!
    See? Even "old monkeys" like myself missed to spot the devilish pin situation!
  • 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);
            }
    
         }
    
    }
    

  • I understand that your "mission" is to be able to "Command/Control" your GSM Module.         However - such a journey is composed of  "many steps."        Your introduction of the GSM Module is likely to bring "new issues" into play - thus "Breaks from KISS" - which firm/I find to be a critical mistake!

    Now you've been "snake-bit" by "PD7 (devil pin)" - and while "not quite" so evil - both your new PB0 & PB1 reveal as (potentially) "troubled pins!"      Long ago - vendor agents placed "Plague-Istors" R9, R10 such that they "tie (connect)" PB0 to PD6 & PB1 to PD7.     Should your board be an "LPad" - and should PD6 or PD7 be configured as GPIO Output - destructive "pin contention" arrives - your doorstep.    If possible - do remove both R9 & R10 - so they may no longer inflict their evil...     (indeed I should have added PB0/PB1 to the list of "'123 LPad suspect pins.")

    Your latest code appears inspired by vendor's offering - which avoided the use of, "Peripheral Ready" checking.        While not (always) required - this "defensive practice" IS "best practice" - and should be adopted.   Your read of the PDL will reveal the "Per. Rdy" function.      (you "loop" on it - insuring that the "just enabled" peripheral - has completed its house-keeping.)

    Plz Standby - middle of the night for me - have to determine the eased availability of a "Safe UART" in your behalf...

    And back: I will list those UART capable Ports/Pins - which are "safe" - AND - which appear upon the "4C'123 LPad's headers" - for eased connection:

    • PC4, PC5    UART_4
    • PC6, PC7    UART_3
    • PE0, PE1    UART_7
    • PE4, PE5    UART_5

    I gleaned this data from w/in the LPad's manual, Pgs. 9-11.      Note that PE0,1 appear upon different headers - making for "messy" interconnect.

    In summary - I'd avoid the introduction of the GSM until AFTER you are able to positively verify the correctness of your "Non UART_0 performance!"       Much time & effort would be saved if you would acquire (again, "Beg, Borrow (legally) obtain a "CMOS to USB Converter" - so that you may "direct connect your" PC to the LPad's "NON UART_0" UART Port.

  • Sure, would be waiting for your response. 

  • 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...

  • Yes, I bought a USB to serial converter and checked the UART, it is working now! :D
    I am moving further to GSM-MUC communication.
    Thanks a lot
  • 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...

  • For whomsoever stuck on the same problem as mine, please note that:

    1) As mentioned by  , PD7 and PF0 are indeed 'Devil ones' and if there's an option, always go for either of UART3, 4, 5, 7 ports.

    2) For me, UART3, 4 worked well, and 5 and 7 too would, but I haven't checked them yet. 

    3) This is the most important conclusion: If you are looking for 'signals' from UART ports to the Oscilloscope, DO NOT WORRY if you get a spike on every receive or transmit of a character. I have spent 60 hours worrying about that until I checked my ports using a Serial to USB (MIND YOU, a TTL level converter, RS232 would destroy your board since it operates at 12V level). So, I am debugging the issue with oscilloscope to find the problem, and I ain't sure but there might be some issue in the sampling or configuration of Oscilloscope.

    Anyways, I'd like to complete my communication with GSM in a couple of days, and again look forward for your all help in future too! Love from India!

    Concluding, a pic of signals on oscilloscope for every transmission or receival, YES they are spikes, and not digital ones as expected, but there's nothing wrong with your UART! Cheers!

    drive.google.com/open

  • 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)

  • Just UART port 3 configuration instead of UART2 worked. Rest nothing changed.
  • OK - for others - Suyash's code - as posted @ 12:54 a.m. , 23 Dec is what has been reported to WORK!

    I would (still) add the, "Check for Peripheral Ready" - an "incompletely initialized peripheral" may not (always) be detected - and can, "Wreck your day ... or days..."