CC2340R2: UART read callback not occurring again if UART read buffer exits

Hi Vignesh,

We have a uart2callback example here: https://dev.ti.com/tirex/explore/node?node=A__AKdlpPkvwtCAe6soBzKbpQ__com.ti.SIMPLELINK_LOWPOWER_F3_SDK__58mgN04__LATEST

For that one, I just modified it so that the input is 248 bytes (UART read buffer).

I do still see the callback being invoked if fewer than 16 bytes are received (specifically, it is taking keyboard input, so any 1 key press is being registered and printed to serial terminal).

/*
 * Copyright (c) 2020, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 *  ======== uart2callback.c ========
 */
#include <stdint.h>
#include <stddef.h>

/* POSIX Header files */
#include <semaphore.h>

/* Driver Header files */
#include <ti/drivers/GPIO.h>
#include <ti/drivers/UART2.h>

/* Driver configuration */
#include "ti_drivers_config.h"

static sem_t sem;
static volatile size_t numBytesRead;

/*
 *  ======== callbackFxn ========
 */
void callbackFxn(UART2_Handle handle, void *buffer, size_t count, void *userArg, int_fast16_t status)
{
    if (status != UART2_STATUS_SUCCESS)
    {
        /* RX error occured in UART2_read() */
        while (1) {}
    }

    numBytesRead = count;
    sem_post(&sem);
}

/*
 *  ======== mainThread ========
 */
void *mainThread(void *arg0)
{
    char input[248];
    const char echoPrompt[] = "Echoing characters:\r\n";
    UART2_Handle uart;
    UART2_Params uartParams;
    int32_t semStatus;
    uint32_t status = UART2_STATUS_SUCCESS;

    /* Call driver init functions */
    GPIO_init();

    /* Configure the LED pin */
    GPIO_setConfig(CONFIG_GPIO_LED_0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    /* Create semaphore */
    semStatus = sem_init(&sem, 0, 0);

    if (semStatus != 0)
    {
        /* Error creating semaphore */
        while (1) {}
    }

    /* Create a UART in CALLBACK read mode */
    UART2_Params_init(&uartParams);
    uartParams.readMode     = UART2_Mode_CALLBACK;
    uartParams.readCallback = callbackFxn;
    uartParams.baudRate     = 115200;

    uart = UART2_open(CONFIG_UART2_0, &uartParams);

    if (uart == NULL)
    {
        /* UART2_open() failed */
        while (1) {}
    }

    /* Turn on user LED to indicate successful initialization */
    GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON);

    /* Pass NULL for bytesWritten since it's not used in this example */
    UART2_write(uart, echoPrompt, sizeof(echoPrompt), NULL);

    /* Loop forever echoing */
    while (1)
    {
        numBytesRead = 0;

        /* Pass NULL for bytesRead since it's not used in this example */
        status = UART2_read(uart, &input, sizeof(input), NULL);

        if (status != UART2_STATUS_SUCCESS)
        {
            /* UART2_read() failed */
            while (1) {}
        }

        /* Do not write until read callback executes */
        sem_wait(&sem);

        if (numBytesRead > 0)
        {
            // print number of bytes no greater than input size
            uint8_t printBytes;
            if (numBytesRead > sizeof(input))
                printBytes = sizeof(input);
            else
                printBytes = numBytesRead;

            status = UART2_write(uart, &input, numBytesRead, NULL);

            if (status != UART2_STATUS_SUCCESS)
            {
                /* UART2_write() failed */
                while (1) {}
            }
        }
    }
}

To try this yourself, you can paste the code to the uart2Callback example.

Can you run your code without BLE? To see if the UART callback is occurring when receiving 16 bytes or fewer.
If the issue is only occurring when BLE is running, then we'll need to consult the BLE experts.

Thanks,
Toby

Hi Toby,

I have tried above code in uart2Callback example. I have sent 250 bytes and data printed on UART was 248 bytes upon sending next 250 bytes, previous packet remaining bytes printing on UART. 

After I have sent 250 bytes and UART read will happened for 248 bytes and data will print on UART and  for those 2 bytes again callback has to occur. 

Thanks,

Vignesh.

Hi Vignesh,

So is this the same issue as with BLE?

vignesh s said:

Upto 16 bytes UART read callback is not occurring.If more than 16 bytes callback is occuring.

^ have you confirmed the following about 16 bytes too?
E.g. try to send

1. 16 bytes or less --> callback occurs?
2. more than 16 bytes --> callback occurs?

For your experiment with uart2Callback:

Is this the same behavior you see in your BLE project?

Can you confirm if this is what you mean?

1. Devices: DUT = CC2340R2, UTX = UART transmitter
2. UTX sends 250 bytes to DUT 
3. DUT receives bytes and UART callback executes, then DUT prints out 248 bytes
4. For remaining 2 bytes not printed (call it UTX-step-2-last-2-bytes) sent by UTX in step 2, DUT has no UART callback
5. UTX sends next 250 bytes to DUT
6. DUT receives bytes and UART callback executes, then DUT prints out UTX-step-2-last-2-bytes AND also the 246 bytes from step 5 (so 2 + 246 = total of 248 bytes printed out). Meaning last 4 bytes from UTX-step-5 is NOT printed out.

Thanks,
Toby

Hi Toby,

Toby said:

So is this the same issue as with BLE?

Yes, The same issue as with BLE.

Toby said:

E.g. try to send

1. 16 bytes or less --> callback occurs?

  -  In BLE code  248 bytes with more than 5 bytes- callback occurs.

Toby said:

more than 16 bytes --> callback occurs?

  - Yes, callback occurring.

Toby said:

For your experiment with uart2Callback:

Is this the same behavior you see in your BLE project?

Can you confirm if this is what you mean?

1. Devices: DUT = CC2340R2, UTX = UART transmitter
2. UTX sends 250 bytes to DUT 
3. DUT receives bytes and UART callback executes, then DUT prints out 248 bytes
4. For remaining 2 bytes not printed (call it UTX-step-2-last-2-bytes) sent by UTX in step 2, DUT has no UART callback
5. UTX sends next 250 bytes to DUT
6. DUT receives bytes and UART callback executes, then DUT prints out UTX-step-2-last-2-bytes AND also the 246 bytes from step 5 (so 2 + 246 = total of 248 bytes printed out). Meaning last 4 bytes from UTX-step-5 is NOT printed out.

Correct, The above sequence has happening in both uart2Callback.c and also with BLE code.

Thanks,

Vignesh.

Hi Vignesh,

Note that for non-blocking mode, there is a RingBuffer which is used (see <ccs project>/Debug/syscfg/ti_drivers_config.c --> uart2RxRingBuffer0).
There may be leftover bytes there due to 250 bytes being sent by UTX vs the 248 bytes being requested in UART2_read.

I think the issue is related to sending more bytes than the buffer can hold.

I recommend to try increasing size of your UART buffer to be at least as large as the max data you expect to have. In your case, it seems to be 250, so size the buffer to 250 (instead of 248). Note that the BLE transmit should still be limited to 248.

Thanks,
Toby