• State
  • Locked Locked
  • Replies 15 replies
  • Subscribers 33 subscribers
  • Views 4485 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

While reading UART with UARTCharsAvail(), it is only reading 255 character

Mayur Paithankar
Prodigy 170 points


Hi

We are using EK-TM4C1294XL Development Board for development with CCS version 6.0.1 and TivaWare_C_Series-2.1.0.12573.

We want to read 4K bytes data from UART .

Receive function is as below:

int reset_buffer=0;

char response_array[1200];

void UARTIntHandler(void)
{

uint32_t ui32Status;

ui32Status = ROM_UARTIntStatus(UART0_BASE, true);
ROM_UARTIntClear(UART0_BASE, ui32Status);
while(ROM_UARTCharsAvail(UART0_BASE)){
char uart_data=ROM_UARTCharGet(UART0_BASE);
response_array[reset_buffer]=uart_data;
SysCtlDelay((g_ui32SysClock)/10000000);
reset_buffer++;
}

While reading response_array, only 255 bytes are shown in response array overwritten in a circular pattern.

This is full resopnce we are getting from server

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
statusCode: 100
statusMsg: Success
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 09 Feb 2016 09:36:10 GMT
Connection: close

96
{"sc":"100","sd":"Success","ct":"1","sa":[{"id":"s1","sr":"30","lr":"0.0","hr":"100.0","lw":"20.0","hw":"80.0","la":"10.0","ha":"90.0","di":"false"}]}
0

In response_array data is shown as below:

0","hr":"100.0","lw":"20.0","hw":"80.0","la":"10.0","ha":"90.0","di":"false"}]}
0
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
statusCode: 100
statusMsg: Success
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 09 Feb 2016 09:36:10 GMT
Connection: close
96
{"sc":"100","sd":"Success","ct":"1","sa":[{"id":"s1","sr":"30","lr":"0.

 

Please help me to solve this issue.

 

 

  • 0
    TI__Guru**** 244410 points
    Hello Mayur

    A circular buffer requires the buffer pointer to be reset back to 0. Where in the code are you resetting the pointers. Also it is unclear the configuration of the device (system clock) and configuration of the UART that has been done.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Hi Amit,

    May I vote for poster's, "reset_buffer++;" as lead candidate for, "most unfortunate naming convention" of the week?    Mixing "reset" with the increment operator - as poster suggests - may not signal great clarity of thought...

  • 0
    Guru 27665 points

    First re-format your code to be readable. There is a past code option that is very helpful for this.

    Mayur Paithankar said:

    void UARTIntHandler(void)
    {

    uint32_t ui32Status;

    ui32Status = ROM_UARTIntStatus(UART0_BASE, true);
    ROM_UARTIntClear(UART0_BASE, ui32Status);
    while(ROM_UARTCharsAvail(UART0_BASE)){
    char uart_data=ROM_UARTCharGet(UART0_BASE);
    response_array[reset_buffer]=uart_data;
    SysCtlDelay((g_ui32SysClock)/10000000);
    reset_buffer++;
    }

    You are missing a } above (I assume you messed up a copy & past but it's not obvious because you did not format the code (see first comment)).

    Mayur Paithankar said:
    SysCtlDelay((g_ui32SysClock)/10000000);

    This does not belong in the reading loop, I suspect it's a result of just pasting in random delays in an attempt to make it work.

    Mayur Paithankar said:
    while(ROM_UARTCharsAvail(UART0_BASE)){

    And this is not a proper loop condition. It will only read until the micro catches up with the sender.

    Your code inevitably reaches either an overrun or starvation condition depending on your delay.

    Robert

  • 0 in reply to Amit Ashara
    Prodigy 170 points
    HI Amit
    Thanks for reply, here is my configuration, we are using 120Mhz freq.

    void configureUART_Xbee(void)
    {
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

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

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

    //
    // Configure the UART for 916,200, 8-N-1 operation.
    //
    IntEnable(INT_UART0);
    UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT);
    UARTConfigSetExpClk(UART0_BASE, g_ui32SysClock,916200,
    (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
    UART_CONFIG_PAR_NONE));
    IntPrioritySet(INT_UART0, 0x20);
    }


    if response is less than 255 byte then it readable, problem only to to read more than 255 byte.Is there any setting to increase the size of reading buffer from 255 to 4K?

    for example:
    if i need to receive 500 byte data, response_array give me last 250 byte first then first 5 byte to complete loop..
    its a simple UART CODE to read data from server with 916200 Baud rate, We checked for different baud rate but same result.Is there problem with UARTIntHandler function?
  • 0 in reply to Amit Ashara
    Prodigy 170 points

    Hi amit

    here is another simple code "uart_echo" to receive data from UART (i used as referance)
    I am using teraterm for communication with 921600 Baud rate. and string is given below
    "1234567890a1234567890b1234567890c1234567890d1234567890e1234567890f1234567890g1234567890h1234567890i1234567890j1234567890k1234567890l1234567890m1234567890n1234567890o1234567890p1234567890q1234567890r1234567890s1234567890t1234567890t1234567890u1234567890v1234567890w1234567890x1234567890y1234567890z"

    on receving i got
    "1234567890a123456163" only

    this my problem

    attached here with project file for uart_echo.

    8306.uart_echo.zip

  • 0 in reply to Mayur Paithankar
    Guru 27665 points
    Note that that is not your stated 255 bytes.

    You do not have a problem with buffer size. Read my previous response, you have written code that cannot be expected to work except by (un)fortunate accident.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    "Unfortunate" accident, indeed.   Perhaps (equally) unfortunate - total reliance upon vendor - and vendor only - for rescue...

  • 0 in reply to Mayur Paithankar
    TI__Guru**** 244410 points
    Hello Mayur,

    I don't think you are considering the forum members input. The pointer is never coming back to start of the buffer besides the points Robert has mentioned.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 170 points
    hi,

    Thanks for reply.

    i know this not usual, i seen such problem first time.May be i missed some step while initializing.

    @ Robert

    i do agreed your first post. i tried with 4-5 types of setting and so i copied one code out of that.
    my simple question is , why i am not able to read more than 255 character. (refer 8306.uart_echo.zip i attached in previous ).
    Is there any other code/function in uart to receive 4K character @ single call?

    @ Amit

    As per my first post i reset the pointer after every uart send request for receiving 4K data, problem occurs due to re-setting counter. but what about the 8306.uart_echo.zip code that i refered. it still not give me valid response.

    Regards
    Mayur
  • 0 in reply to Mayur Paithankar
    Guru 27665 points
    Between your delay and loop test condition I think getting anything reasonable out of this is purely accidental. I can imagine many kinds of behaviour depending on the timing of the sender and receiver.

    The first question you need to ask, how do you know when the sender is finished?

    Robert
  • 0 in reply to Mayur Paithankar
    Guru 27665 points

    Mayur Paithankar said:
    i tried with 4-5 types of setting and so i copied one code out of that.

    Yoda said:
    There is no try

    Seriously, you have to design the communications, not cut and patch to see if something works.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    Seriously, you have to design the communications

    Well said - perhaps another version reads, "Thought, plan before action!"   Action may (temporarily) soothe - yet long-term - minus "design" - efforts are most always condemned to mediocrity...

    Firm/I note that too often, "Try - try - try" (repeats) the mistakes of the earlier (failed) "try" efforts.   And often this is not even noted!

    It is not "practice" which makes perfect.   It is "perfect practice" (i.e. designed practice) which makes perfect.   Try - try - try (minus a methodical plan) wins few battles...  (deservedly so)

  • 0 in reply to cb1
    Prodigy 170 points

    Hi 

    Problem solved out.. its being Frequency  issue (timing on receiver hardware problem)..

    Thanks Robert & Amit

    Regards

    Mayur

  • 0 in reply to Mayur Paithankar
    Guru 47900 points
    So - we're (now) asked to believe that 255 bytes arrive (well timed) - and byte 256 (suddenly) suffers "frequency deviation." Really?
  • 0 in reply to cb1
    Guru 27665 points
    I share the incredulity, one of the strengths of standard asynchronous serial UARTs is they resynchronize on every character.

    And, Mayur, if you have not substantially modified the code you showed you still have a significant problem.

    Robert