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: uart not sending all chars only 2 are sent

Part Number: TM4C123GH6PM

hello , i recently bought a node mcu with esp8266 wifi module and i was trying to get it to communicate with my tiva c microcontroller , i was trying to send a simple sentence dofile("script1.lua") which should make the led on the node mcu to blink , sending this via a serial monitor using putty works on the node mcu with no issues , however using the micrcontroller with the same settings as putty doesnt work in fact when both the microcontroller and the nodemcu are connected through usb on my laptop i can see that only 2 letters are being sent , d and o the first 2 letters in my sentence nothing else is being sent , any idea what might be happening with my tiva c ? 

here is the full code i am using to send the dofile like and then waiting if anything is received from the node mcu

#include "tm4c123gh6pm.h"

void UART2_Init(void);
void UART2_Send_Char(char c);
void UART2_Send_String(char *string);
char a;
int main()
{
	volatile int delay=0;
	UART2_Init();
	for(delay=0;delay<10000;delay++);
	UART2_Send_String("dofile(\"script1.lua\")\n\r");
	while(1)
	{
		while((UART2_FR_R & (1<<4))!=0);
		a=UART2_DR_R;
	}
}
void UART2_Send_Char(char c)
{
	while((UART2_FR_R & 0x040) != 0);
	UART2_DR_R = c;	
}
void UART2_Send_String(char *string)
{
	while(*string)
	{
		UART2_Send_Char(*(string++));
	}
}
void UART2_Init(void)
{
	//1. Enable the UART module using the RCGCUART register (see page 342).
	//enable clock 5
	SYSCTL_RCGCUART_R |= 0x04;
	//2. Enable the clock to the appropriate GPIO module via the RCGCGPIO register (see page 338).
	//enable clock for port D
	SYSCTL_RCGCGPIO_R |= 0x08;
	//To find out which GPIO port to enable, refer to Table 23-5 on page 1344.
	//digital enable the pins on port D
	GPIO_PORTD_LOCK_R =0x4C4F434B;
	GPIO_PORTD_CR_R = 0xFF;
	GPIO_PORTD_DEN_R |= 0xFF;
	//3. Set the GPIO AFSEL bits for the appropriate pins (see page 668). To determine which GPIOs to
	//configure, see Table 23-4 on page 1337.
	//alternate functions on pins PD6 and PD7 ,PD6 -> uart5 rx , PD7 -> uart5 tx
	GPIO_PORTD_AFSEL_R |= 0xC0;
//5. Configure the PMCn fields in the GPIOPCTL register to assign the UART signals to the appropriate
//pins (see page 685 and Table 23-5 on page 1344).
	GPIO_PORTD_PCTL_R |= 0x11000000;
//This section discusses the steps that are required to use a UART module. For this example, the
//UART clock is assumed to be 16 MHz, and the desired UART configuration is:
//1- 115200 baud rate
//2-data length 8bits
//3-one stop bit
//4-no parity
//5-no fifos
//6-no interrupts
//disable the uart3
	UART2_CTL_R &=0xFE;
//get values for IBRD and FBRD from the data sheet page 900
	UART2_IBRD_R = 8;
	UART2_FBRD_R = 44;
//set the appropriate bits in LCRH for the configuration stated above
	UART2_LCRH_R |= 0x60;
//clock source = system clock
	UART2_CC_R &=00;
//enable the uart module
	UART2_CTL_R |=0x301;
}


  • Essam Eid said:
    any idea what might be happening with my tiva c ?

    I haven't attempted to fully understand the code since it is written in Direct Register Mode (DRM) with magic numbers for the register fields, rather than the easier to understand TivaWare APIs.

    If you want to use DRM for "learning" purposes suggest you at least use the macros from the Tivaware hw_*.h include files for the register fields.

    The following code looks suspect, since the value 0x40 is the UART Receive FIFO Full (RXFF) flag, where I think the code should instead be testing the UART Transmit FIFO Full (TXFF) flag:

    void UART2_Send_Char(char c)
    {
    	while((UART2_FR_R & 0x040) != 0);
    	UART2_DR_R = c;	
    }

    Suggest you include the inc/hw_uart.h file and then try the following code to see if that fixes your problem:

    void UART2_Send_Char(char c)
    {
    	while((UART2_FR_R & UART_FR_TXFF) != 0);
    	UART2_DR_R = c;	
    }

  • thank you very much i missread the bit number sorry for wasting your time :)
  • Loved your use of "magic numbers" - might the "alchemy" demanded by DRM - divert users from their "solution focus" - while "eating" time/effort?     (So, so much MCU page searching/turning - and individual register bit examining...)

    And for what?     Day - maybe two (after) "laser focus upon key/critical register bits" - all will be forgotten - and the archaic process must be launched (again) from "square one!"    Who can call that, "learning?"

    API - in contrast - is, "Tried, True, Tested" - enables "real" problem solving - minus user "exhaustion," excess effort & great time investment.    Is not (some) attention to be directed to, "becoming Productive?"   (offered - overwhelmingly - by (only) the API.)    Use of the API - in no way prevents nor limits, "Register Examination" - it is that point which is "glossed over."    Why is that?

    While you've listed the quasi official definition of DRM - invention & experience suggest, "Delightfully Regressive Monstrosity."