Compiler/TM4C123GE6PM: Tiva c UART

NO i am not able to solve that problem. I tried with using different buffer still it's not working. After reading 15 Bytes it's giving me 0xff.

Hello Ralph, I am not using any ISR to handle UART . I am simply using UARTCharGetNonBlocking(UART3_BASE)  for taking data in to buffer.

while (UARTCharsAvail(UART3_BASE))

{

 buffer_cmgr [k++] =UARTCharGetNonBlocking(UART3_BASE);

}

I am getting first 16 Bytes correctly but after that i am getting \xff. My actual data is present at between 30 to 35 bytes. 

And about that AT command, AT+CMGR=1 is used for reading the incoming text message from Phone.

Here i am trying to read the incoming message sent from phone.

Hello Ralph, Thank you for your quick response. Actually I am using UART3.

CODE-

#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include "inc/hw_gpio.h"
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "inc/hw_ints.h"
#include "driverlib/fpu.h"
#include "driverlib/debug.h"
#include "driverlib/sysctl.h"
#include "driverlib/pin_map.h"
#include "driverlib/gpio.h"
#include "driverlib/pwm.h"
#include "driverlib/timer.h"
#include "driverlib/adc.h"
#include "utils/uartstdio.h"
#include "utils/cmdline.h"
#include "driverlib/uart.h"
#include "driverlib/interrupt.h"
#include "inc/hw_ints.h"
#include "driverlib/interrupt.h"
#include "driverlib/hibernate.h"
#include "driverlib/rom.h"
#define MAX 50


int temp;
int temp1;
int temp2;
char buffer_at[5];
char buffer_cmgf[5];
char buffer_cmgr[50];
char buffer_cmgr1[25];
int i=0;
int j=0;
int k=0;
int l=5;
char data;
/********************************Function Decleration******************************/
void UARTSend(const uint8_t *pui8Buffer, uint32_t ui32Count);

/*********************************Main Function*************************************/
void main(void)
{
	int response_AT;
	int count=0;
	int count1=0;
	for(count=0;count<=5;count++)
		SysCtlDelay(SysCtlClockGet() / (4)); // 1sec

	/**********************************UART INIT********************************************************/
	SysCtlPeripheralEnable(SYSCTL_PERIPH_UART3);
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
	//HWREG(GPIO_PORTC_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
	//HWREG(GPIO_PORTC_BASE + GPIO_O_CR) = 0x80;
	GPIOPinConfigure(GPIO_PC6_U3RX);
	GPIOPinConfigure(GPIO_PC7_U3TX);
	GPIOPinTypeUART(GPIO_PORTC_BASE, GPIO_PIN_6 | GPIO_PIN_7);
	UARTConfigSetExpClk(UART3_BASE, SysCtlClockGet(), 9600,(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |UART_CONFIG_PAR_NONE));
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
	GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

	/*------clearing the rec buffer of uart3------*/
	while(UARTCharsAvail(UART3_BASE))
		temp = UARTCharGetNonBlocking(UART3_BASE);

	/*------to turn the echo off---*/
	UARTSend((uint8_t *)"ATE0", 4);
	SysCtlDelay(SysCtlClockGet() / (8)); //0.5sec
	UARTCharPutNonBlocking(UART3_BASE, 0x0d);
	while(UARTCharsAvail(UART3_BASE))
	{
		temp1=UARTCharGetNonBlocking(UART3_BASE);
	}
	SysCtlDelay(SysCtlClockGet() / (4)); // 1sec
	/*----------------sending message to the first mobile number------------------------------------*/
	while(1)
	{
		UARTSend((uint8_t *)"AT", 2);
		SysCtlDelay(SysCtlClockGet() / (8));
		UARTCharPutNonBlocking(UART3_BASE, 0x0d);
		response_AT=UARTCharGet(UART3_BASE);
		if (response_AT!=69)
		{
			break;
		}
		break;
	}
	while(UARTCharsAvail(UART3_BASE))
	{
		buffer_at[i++]=UARTCharGetNonBlocking(UART3_BASE);
	}


	/*------clearing the rec buffer of uart3------*/
	while(UARTCharsAvail(UART3_BASE))
		temp = UARTCharGetNonBlocking(UART3_BASE);


	while(1)
	{
		UARTSend((uint8_t *)"AT+CMGF=1", 9);
		SysCtlDelay(SysCtlClockGet() / (8));
		UARTCharPutNonBlocking(UART3_BASE, 0x0d);
		response_AT=UARTCharGet(UART3_BASE);
		if (response_AT!=69)
		{
			break;
		}
		break;
	}
	while(UARTCharsAvail(UART3_BASE))
	{
		buffer_cmgf[j++]=UARTCharGetNonBlocking(UART3_BASE);
	}


	/*------clearing the rec buffer of uart3------*/
	while(UARTCharsAvail(UART3_BASE))
		temp2 = UARTCharGetNonBlocking(UART3_BASE);


	while(1)
	{
		UARTSend((uint8_t *)"AT+CMGR=1", 9);
		SysCtlDelay(SysCtlClockGet() / (8));
		UARTCharPutNonBlocking(UART3_BASE, 0x0d);
		response_AT=UARTCharGet(UART3_BASE);
		if (response_AT!=69)
		{
			break;
		}
		break;
	}

	while(UARTCharsAvail(UART3_BASE))
	{
		buffer_cmgr[k]=UARTCharGetNonBlocking(UART3_BASE);
		k++;
	}
}

/*----------To send commands to GSM module -----------------------*/
void UARTSend(const uint8_t *pui8Buffer, uint32_t ui32Count)
{
	while(ui32Count--)
	{
		UARTCharPutNonBlocking(UART3_BASE, *pui8Buffer++);
	}
}

I want to read the following string,

+CMGL: 1,"REC READ","+85291234567",,"07/02/18,00:05:10+32"

But i can read up to 16 bytes. I am able to read up to 16 bytes .I want read remaining bytes also.

In this code i am reading response of AT commands. In last buffer_cmgr i want to read more than 16 bytes.

Hello Ralph, Did you tried with same AT commands. And if i try to use UART0, What about connection with GSM module. 

Thank you.

Indrajeet Hujare said:

char buffer_cmgr[50];

Indrajeet Hujare said:

+CMGL: 1,"REC READ","+85291234567",,"07/02/18,00:05:10+32"

The following is noted - may prove of interest:

• None of the 3 receive buffers (buffer_at, buffer_cmgf, buffer_cmgr) has its 'buffer counter' (i, j, or k) ever cleared (beyond the initial code set-up.)
• If  '+CMGL' is (really) part of the 'CMGL' String - then the 50 byte limit of buffer_cmgr has been exceeded.   (I counted 56 bytes, total)
• As the UART's Receive FIFO contains (up to) 16 bytes - and 16 bytes are the maximum which poster is able to successfully receive - does this not suggest a (likely) Receive FIFO issue?
• Vendor suggested 'loss of UART Data Arrival - post these initial 16 bytes' - appears, "Not really the case" - poster reports receiving 0xFF - although (not) the number of such 0xFF transmissions!

Now vendor's Ralph reports success when sending,  'greater than 16 bytes via UART_0.'      Yet there are two weaknesses in that method:

• poster is using UART_3 - which may have altered constraints
• Ralph may be 'manually entering' his data - while the poster's device is sending data at a (more likely) faster character rate.   (not baud rate - that's unchanged)     A better test may result if Ralph could 'first package his data' - so that the package exceeds 16 bytes - and is transferred at a consistent character rate.    (i.e. other than manual/keyboard data entry - which IS suspected.)

A good read of the MCU manual AND the PDL user manual - could not (clearly/completely) reveal how the UART's Receive FIFO behaves - when data arrives when that Receive FIFO is FULL.   (i.e. at 16 byte capacity.)     The following is noted - via UART Register, 'UARTDR' ...  Bit 11 (OE) ...  "New data was received when the FIFO was full, resulting in data loss."   

One must wonder - is such data (really) at all - clear & complete?     This UART Receive FIFO area (most likely) - warrants greater (i.e. SOME) improved & detailed - vendor descriptive efforts...

Thank you - earlier you reported receiving, 'Additional Bytes' - beyond those initial (correct - first 16 (bytes.)
Is this (still) the case?     And - are each of these bytes always the same value.   (you reported 0xFF - earlier)
How many of these 'improper' bytes do you regularly receive?    

Your code reveals, No clearing of  ANY  of your buffer_counters - after the buffers have been exercised.   (loaded)     Thus - if you call those buffer loads again - all such counters start from HIGH Values - which is NOT what you want!      (all such "requested data'  (this post)  will assist in your solution...)

Do note - I'm at a show, 'Automatica' in Munich - and 'booth duty' prevents my response (now) for many hours...

Hello Indrajeet,

Indrajeet Hujare said:

Did you tried with same AT commands. 

I do not have the module you are using, so I can't try that on my end unfortunately. This is why I have requested that you scope the lines to ascertain that the module is correctly sending out the packet you expect.

Indrajeet Hujare said:

And if i try to use UART0, What about connection with GSM module. 

I wasn't suggesting you try UART0, I just wanted to highlight how I performed the test on my end. And to answer another query...

cb1_mobile said:

poster is using UART_3 - which may have altered constraints

There is no indication in either DS or Errata sheet that there is any constraints on UART3, which is why I felt using UART0 was accurate enough.

Indrajeet Hujare said:

I tried lot but this polling method is not working. After getting 16 Bytes its giving me -1. That is no data available in UART. My UART is not able to get more than 16 Bytes. Can you suggest another method.

You can certainly try out using interrupts. Our uart_echo example in TivaWare does this and the setup is straightforward. However, you will need to reduce your multiple RX buffers to a single RX buffer and do proper data processing as you need to ensure the ISR code is fairly lean.

cb1_mobile said:

Ralph may be 'manually entering' his data - while the poster's device is sending data at a (more likely) faster character rate.   (not baud rate - that's unchanged)     A better test may result if Ralph could 'first package his data' - so that the package exceeds 16 bytes - and is transferred at a consistent character rate.    (i.e. other than manual/keyboard data entry - which IS suspected.)

I used a UART terminal to send large packets over, so while I did create the packet with the keyboard, it sent all 30+ bytes in a constant data stream, not at the speed of my fingers typing :)

cb1_mobile said:

Vendor suggested 'loss of UART Data Arrival - post these initial 16 bytes' - appears, "Not really the case" - poster reports receiving 0xFF - although (not) the number of such 0xFF transmissions!

Well, I asked before the following: "You mention you get 0xFF after 16 bytes, how many more bytes do you receive until the loop stops because there is no more UART data available?"

And received no clear answer aside from "But i can read up to 16 bytes. I am able to read up to 16 bytes .I want read remaining bytes also."

So I don't really understand yet if the remaining bytes that are expected are just being read wrong, don't arrive at all, take longer to arrive than expected, etc. - this where I am hoping that scoping the UART lines could clearly show if the data has been transmitted to the TM4C in a continuous stream and that the issue really does lie within the UART RX method.