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.

CCS/SW-EK-TM4C1294XL: UART POrt 6 not working on launchpad

Part Number: SW-EK-TM4C1294XL

Tool/software: Code Composer Studio

Hi

I am trying to configure UART6 p on Launchpad kit (pins 118 an 119 as U6 Rx and Tx). But the program crashes on trying to set baud rate. On commenting out, no data is seen on the pins 119 and 118.

I am attaching the program

The define switch #deifine UART6_LAUNCHPAD chooses U6

if this is commented out, the original UART0 operates in console mode with serial port.

Thanks

Pavitra

uart_echo.c
//*****************************************************************************
//
// uart_echo.c - Example for reading data from and writing data to the UART in
//               an interrupt driven fashion.
//
// Copyright (c) 2013-2016 Texas Instruments Incorporated.  All rights reserved.
// Software License Agreement
// 
// Texas Instruments (TI) is supplying this software for use solely and
// exclusively on TI's microcontroller products. The software is owned by
// TI and/or its suppliers, and is protected under applicable copyright
// laws. You may not combine this software with "viral" open-source
// software in order to form a larger program.
// 
// THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
// NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
// NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
// CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
// DAMAGES, FOR ANY REASON WHATSOEVER.
// 
// This is part of revision 2.1.3.156 of the EK-TM4C1294XL Firmware Package.
//
//*****************************************************************************

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

//*****************************************************************************
//
//! \addtogroup example_list
//! <h1>UART Echo (uart_echo)</h1>
//!
//! This example application utilizes the UART to echo text.  The first UART
//! (connected to the USB debug virtual serial port on the evaluation board)
//! will be configured in 115,200 baud, 8-n-1 mode.  All characters received on
//! the UART are transmitted back to the UART.
//
//*****************************************************************************
#define UART6_LAUNCHPAD
//****************************************************************************
//
// System clock rate in Hz.
//
//****************************************************************************
uint32_t g_ui32SysClock;

//*****************************************************************************
//
// The error routine that is called if the driver library encounters an error.
//
//*****************************************************************************
#ifdef DEBUG
void
__error__(char *pcFilename, uint32_t ui32Line)
{
}
#endif

//*****************************************************************************
//
// The UART interrupt handler.
//
//*****************************************************************************
void
UARTIntHandler(void)
{
    uint32_t ui32Status;

    //
    // Get the interrrupt status.
    //
    ui32Status = ROM_UARTIntStatus(UART0_BASE, true);

    //
    // Clear the asserted interrupts.
    //
    ROM_UARTIntClear(UART0_BASE, ui32Status);

    //
    // Loop while there are characters in the receive FIFO.
    //
    while(ROM_UARTCharsAvail(UART0_BASE))
    {
        //
        // Read the next character from the UART and write it back to the UART.
        //
        ROM_UARTCharPutNonBlocking(UART0_BASE,
                                   ROM_UARTCharGetNonBlocking(UART0_BASE));

        //
        // Blink the LED to show a character transfer is occuring.
        //
        GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, GPIO_PIN_0);

        //
        // Delay for 1 millisecond.  Each SysCtlDelay is about 3 clocks.
        //
        SysCtlDelay(g_ui32SysClock / (1000 * 3));

        //
        // Turn off the LED
        //
        GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 0);
    }
}

//*****************************************************************************
//
// Send a string to the UART.
//
//*****************************************************************************
void
UARTSend(const uint8_t *pui8Buffer, uint32_t ui32Count)
{
    //
    // Loop while there are more characters to send.
    //
    while(ui32Count--)
    {
        //
        // Write the next character to the UART.
        //
        ROM_UARTCharPutNonBlocking(UART0_BASE, *pui8Buffer++);
    }
}

//*****************************************************************************
//
// This example demonstrates how to send a string of data to the UART.
//
//*****************************************************************************
int
main(void)
{
    //
    // Set the clocking to run directly from the crystal at 120MHz.
    //
    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN |
                                             SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), 120000000);
    //
    // Enable the GPIO port that is used for the on-board LED.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);

    //
    // Enable the GPIO pins for the LED (PN0).
    //
    ROM_GPIOPinTypeGPIOOutput(GPIO_PORTN_BASE, GPIO_PIN_0);

#ifndef UART6_LAUNCHPAD
    // Enable the peripherals used by this example.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    // Enable processor interrupts.
      //
      ROM_IntMasterEnable();

      //
      // Set GPIO A0 and A1 as UART0 pins.
      //
      GPIOPinConfigure(GPIO_PA0_U0RX);
      GPIOPinConfigure(GPIO_PA1_U0TX);
      ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);



      // Configure the UART for 115,200, 8-N-1 operation.
      //
      ROM_UARTConfigSetExpClk(UART0_BASE, g_ui32SysClock, 115200,
                              (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                               UART_CONFIG_PAR_NONE));



      // Enable the UART interrupt.

     ROM_IntEnable(INT_UART0);
     ROM_UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT);
#endif

#ifdef UART6_LAUNCHPAD
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART6);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOP);

    // Enable processor interrupts.
       //
       ROM_IntMasterEnable();

    // set up PP0 and PP1 as UART6 pins
        GPIOPinConfigure(GPIO_PP0_U6RX);
           GPIOPinConfigure(GPIO_PP1_U6TX);
     ROM_GPIOPinTypeUART(GPIO_PORTP_BASE, GPIO_PIN_0 | GPIO_PIN_1);
     // Configure the UART for 115,200, 8-N-1 operation.
     ROM_UARTConfigSetExpClk(UART6_BASE, g_ui32SysClock, 115200,0);
                         //        (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                         //         UART_CONFIG_PAR_NONE));
     // Enable the UART interrupt.
     ROM_IntEnable(INT_UART6);
         ROM_UARTIntEnable(UART6_BASE, UART_INT_RX | UART_INT_RT);

#endif


    // Prompt for text to be entered.
    //
#ifndef UART6_LAUNCHPAD
    UARTSend((uint8_t *)"\033[2JEnter text: ", 16);
#endif
    //
    // Loop forever echoing data through the UART.
    //
    while(1)
    {
#ifdef UART6_LAUNCHPAD
        HWREG(UART6_BASE + 0) = '|';
#endif
#ifndef UART6_LAUNCHPAD
        HWREG(UART0_BASE + 0) = '|';
#endif
        SysCtlDelay(1000000);
    }
}

  • Great "parallelism" (to your working UART0) appears w/in your set-up/configuration of UART6 - good that!

    Is it possible that the "ROM function" for: "UARTConfigSetExpClk()" does NOT extend to include "UART6?"     You may employ the "Flash function" to test that theory.

    Surely you noted that UART6 - by itself - is unable to generate or safely respond to, "other than "3V3" voltage levels."    (I don't believe that UART6 is routed thru the "ICDI" - you should confirm that belief.)

  • Pavitra,

    There is nothing wrong with your piece of code that configures UART6. It does not crash, I tested here.

    Take a better look when you say the program crashes "on trying to set the baud rate". It is something else. Where does the execution go to when you say "crash"?

    One possibility could be that the peripheral was not yet ready when you tried to configure it: add a while(SysCtlPeripheralReady(YOUR_PERIPH)); after enabling each peripheral, just as a good practice. But still, your UART6 is quite far after the enabling for that to be the case (unless there is something bad with your hardware...) Might even be the case you don't have enough stack size.

    After configuring a UART pin, the TX signal shall be permanent high (except during the time you are sending bytes). Can you confirm that's the case? Where are you trying to "see" the sent characters? A scope? A RS232 receiver? A logic analyzer? Another launchpad???

    Regards

    Bruno

  • Bruno Saraiva said:
    One possibility could be that the peripheral did not enable properly

    Word-play enters here - does it not?      What do you mean by, "enable properly?"       Is it possible to (partially) enable?       (Ruling out any (deliberate/artful) attempt/method to achieve such "partial enabling.")

    Should the peripheral "not" be enabled - we'd expect a crash far earlier (upon first call to that peripheral function) - would we not?

    Poster does "break" from (parallelism to UART0) via reducing the (usual) 3 final parameters to their "logical OR" (0) - shown w/in his code.     Might the ROM function "stumble" on that?     (I know that poster Bruno often uses MAP rather than ROM - which would (avoid) any ROM issue - when calling that  "UARTConfigSetExpClk()"  function.)

  • cb1_mobile said:
    What do you mean by, "enable properly?"       Is it possible to (partially) enable?

    Actually, yes, it is!

    The practice here for any peripheral is:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH);
    
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOH)){}
    
    

    (yes, with MAP_ and of course the proper periph macro)

    The peripherals can take a few cycles to be ready, and an attempt to immediately try to access them right after enabling can cause to Fault. Honestly, I've never seen that happen because there is usually some lines of mumble code after the enabling, but... 

    If I remember his code correctly, the line where he says he had the crash was the first poking into such peripheral... 

    cb1_mobile said:
    reducing the (usual) 3 final parameters to their "logical OR" (0)

    Nope, there's just something else wrong with the rest of his code. I pasted his UART6 code into my project and the UART gets configured just fine - the crashing is likely not to be where posted.

    I don't trust things like "UARTPrintf", UARTSend... not that they don't work, but when I started with those, they were had-coded to UART0 only, and required changes for other ports, so in the end we have our own.

    Bruno

  • We still are w/in a "definition/meaning" debate. I know (and have long known) of the necessity to provide adequate time for the peripheral to "awaken."

    Yet your use of "enable properly" suggests (other) than, "Enabled or Disabled!" (i.e. partially enabled)     That's my point!     I propose your (otherwise correct) language to shift to: "Could be the peripheral did NOT ENABLE!"       That "Enable" should be "Black or White" (i.e. Enabled or Disabled) - excluding any "partials" (even those "artfully" produced!)

    I'm at an airport - laptop crashed - and I had added a clause (post above) addressing any "artful" attempt to "Partially Enable a Peripheral." (which MAY be possible - and (that) is the saving hedge for your use of "properly" enable.)

  • First reply properly edited - just in case!
  • Ahhh - and note our (thoughtful) poster has provided a "double dose" of motivation! (took ALL of my will-power to avoid ( ).)

    It is strange that our field - where 999 correct code lines - and ONE single errant one - will (fairly) label us as, "Bums!"      Thus - great attention should be paid to our writings - descriptions - objectives - always w/the goal of reducing (ideally eliminating) vagueness!         (i.e. how does one code to a "vague" requirement - worse still - how to draw a contract to multiple "vague" requirements?)

    I hear (several) ask, "Why such mention - big deal!"      Precision w/in the project's definition - and operation - makes the code FASTER & EASIER to Develop & Test - and best enables the legal crüe to "navigate quickly/smoothly thru the proposal/contract's, "deliverable forest."                             (i.e. "properly" (earlier appearing right here) is defined by whom?      thus should be avoided...)

  • cb1_mobile said:
    where 999 correct code lines - and ONE single errant one - will (fairly) label us as, "Bums!"

    Medicine: 999 correct surgeries and 1 errant labels as a liability...

    Aviation: 999 correct landings and 1 crash labels as history...