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/TM4C1294NCPDT: Problem with UART

Part Number: TM4C1294NCPDT

Tool/software: Code Composer Studio

Hi,

Attached is small piece of code that is supposed to send data from the board to the PC via serial link. However, I'm not receiving anything on my PC.

Also, when I check UART0_DR register in the debug mode, DATA bits are empty. The settings of the putty are the same as in the board (9600,8,1,none).

#include <stdint.h>
#include <stdbool.h>
#include "C:\ti\TivaWare_C_Series-2.1.4.178\inc\hw_memmap.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\inc\hw_types.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\sysctl.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\gpio.h"
#include "C:\ti\TivaWare_C_Series-2.1.4.178\inc\tm4c1294ncpdt.h"


void delayMs(int a);
void UART0Tx(char c);

int main(void)
{
//SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480), 120000000);

SYSCTL_RCGCUART_R|=0X01;
while ((SYSCTL_PRUART_R & 0x01) != 0x01){};

UART0_CTL_R&=~(0X00000000);
UART0_IBRD_R=104;
UART0_FBRD_R=11;
UART0_LCRH_R=0X60;
UART0_CC_R=0X00;
UART0_CTL_R=0X301;


SYSCTL_RCGCGPIO_R=0x01;
while ((SYSCTL_PRGPIO_R & 0x01) != 0x01){};

//GPIO_PORTA_AHB_AMSEL_R=0x00;
GPIO_PORTA_AHB_PCTL_R=0X11;
GPIO_PORTA_AHB_AFSEL_R|=0X03;

GPIO_PORTA_AHB_DEN_R=0X03;

//delayMs(1);
while(1)
{
UART0Tx('t');
UART0Tx('e');
UART0Tx('s');
UART0Tx('t');
UART0Tx(' ');
}

}

void delayMs(int n)
{
int i,j;
for(i=0;i<n;i++)
{
for(j=0;j<3180;j++)
{
;
}
}

}

void UART0Tx(char c)
{
while((UART0_FR_R & 0X80)!=0X80){};
UART0_DR_R=c;
delayMs(10);

}

Does anyone have a clue?

Regards

  • peter_mm_2018 said:
    Does anyone have a clue?

    Indeed - but you won't be pleased!     

    It is apparent that you have been "ordered" to employ (ONLY) the "DRM" style of coding - which while claiming,  "Significant MCU UNDERSTANDING" - most always results in posters landing here - unable to get the "most basic of functions" to perform!     Pardon - but just WHEN - and WHERE - is such (claimed) "Advanced Understanding" to occur?     And WHY - do SO MANY of your (enforced) DRM fellows - SO OFTEN FAIL?

    You "Cull yourself substantially from the "FAR MORE SUCCESSFUL - AND ACHIEVING "API HERD" - by surrendering to the archaic, delaying - and (always)  MINIMALLY  tested  (if at all) DRM style of coding.    

    The API has been successfully employed by THOUSANDS - it is proven to be ROBUST and EXTENSIVE - and may be used in concert w/the MCU Manual - to provide "GREAT REGISTER BEHAVIOR EXAMINATION & PROBING!"    (Never/ever - even "hinted at" - by DRM proponents!)

    Multiple UART examples exist - w/in the vendor's API - these are: PROVEN, WELL COMMENTED, and (most always) COMPLETELY AVOID THE "PAINFULLY FLAWED RESULTS" - you and (many other) "DRM" users (regularly/predictably) SUFFER!

    Might your "switch to the API" - prove a valid/worthwhile "clue?"     (MANY  (interested in efficiency & achievement) believe that to, "be the case!")

  • Should I put now "This resolved my issue"? :)
  • Only if you find my "UCLA law" logic - somewhat compelling.
    Has the case not been (overwhelming made) - in favor of the API? If so - "This Resolved"- proves highly appropriate."

    You will note that MOST ALL Vendor Agents (also) discourage the use of such "archaic methods."     They EAT time & effort - and FOR WHAT?    

    The RACE is "To the SWIFT" - NOT to the overly complex - where any/all "added learning" proves  NOT SUPPORTED (nor comes anywhere close) to being reality...

  • "The DRM approach is to access the peripheral's special function registers directly using C language and
    create your own custom library since you have total control over each function. Much of these functions can
    be modified and used with another vendor if you decide to change the ARM chip vendor. This approach is difficult and tedious, but the rewards are great"
  • That IS an "overly broad" and "overly optimistic" - series of claims - is it not?

    You may note that a "far superior method" - capable of (really) achieving both objectives - already exists.

    The "difficult & tedious" is surely agreed - "rewards are great" - based upon their time & effort investment - NOT so much!     And it is HIGHLY NOTED - that any/all  "Purported Benefits of  "DRM" - are (always) "masked" in such vague (and unmeasurable) terms!     Why is that?     And what rewards?    And what proves "great?"    (beyond VERY Wishful Thinking!)

    Pity that my (rather detailed) suggestion did NOT rise to accepted, "clue" status.     (might (some) fairness (even honesty) (also) have, "landed w/DRM code - upon the rocks?)

  • Hello Peter,

    cb1 is speaking in alignment with what we at TI can support. TivaWare was constructed to remove the time & effort of learning painstakingly how to use DRM calls with our MCU to allow all customers quicker development paths and more robust systems. The TivaWare API's are well tested and used by 100's of customers. We do not have the time to support applications which seek to reinvent our finely tuned wheel, so I would ask that you use TivaWare for your application if you desire to get support from TI.

    You can always re-translate your working TivaWare code back into DRM calls if it so pleases you after the fact...