LAUNCHXL-CC1310: UART_write() not calling the callback function - nortos

Yeah I noticed the blocking UART_write() call in the callback, and you are right as I had suspected when I saw that. It runs if you put the uart write mode into callback mode as you said. Elsewhere in the documentation (locally installed with the SDK) it tells us not to use blocking calls in a callback, which makes sense as we would typically try to avoid that anyways. There seems to be another bug as well, as that example works great if you want to grab wantedRxBytes each time without ever getting a partial. The page says that "Note: The partial return is also possible in UART_MODE_CALLBACK mode." bit this seems to be not accurate, as if you call: UART_control(uart, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL); you will never receive any data. I've been messing with the code example that Fred posted for a bit. I think I'm going to try what you posted now and see how that is going to work.

I really like the idea of sending a batch/block of data when it comes in quick enough, but sending what you have if you timeout. My planned deployment of this is basically just a UART->RF->UART connection between CC1310's to use them as a link similar to the ones used for hobby drone telemetry (3DR radio pairs), but also having the ability to ad more functionality, such as star topology and simple robot and intelligent fixture control. It's looking like partial receives with a timeout but in callback mode isn't well supported by the driver. Perhaps that works much better when using TIRTOS? Also, I may be able to just deal with getting a byte at a time.

There should be no problem with return partial in callback mode. Trying it out on my version of the uartecho, doing 100 byte reads with return partial enabled, I'm still able to receive the single byte callbacks.

When in your code are you calling the UART_control(uart, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL); part? You should call it before the initial read call, if not the initial call won't take this into account and perform a "normal" read.

M-W's solution seems to work the best, but the link that Fred posted is definitely worth a read as that info is not easy to find when you are using the locally installed documentation that comes with the SDK

What I have now is this:

#include <stdint.h>
#include <stddef.h>

/* Driver Header files */
#include <ti/drivers/GPIO.h>
#include <ti/drivers/UART.h>
#include <ti/drivers/uart/UARTCC26XX.h>

/* Example/Board Header files */
#include "Board.h"


#define MAX_NUM_RX_BYTES    1000   // Maximum RX bytes to receive in one go
#define MAX_NUM_TX_BYTES    1000   // Maximum TX bytes to send in one go
uint32_t wantedRxBytes = 16;        // Number of bytes received so far
uint8_t rxBuf[MAX_NUM_RX_BYTES];   // Receive buffer
uint8_t txBuf[MAX_NUM_TX_BYTES];   // Transmit buffer


// Callback functions
static void readCallback(UART_Handle handle, void *rxBuf, size_t size)
{
    // turn on green led to to indicate we received uart data
    GPIO_write(Board_GPIO_LED1, Board_GPIO_LED_ON);
    // Make sure we received all expected bytes
    if (size == wantedRxBytes) {
        // Copy bytes from RX buffer to TX buffer
        for(size_t i = 0; i < size; i++)
            txBuf[i] = ((uint8_t*)rxBuf)[i];
        // Echo the bytes received back to transmitter
        UART_write(handle, txBuf, size);

    }
    else {
        // Handle error or call to UART_readCancel()
    }
}

static void uartWriteCallbackFxn (UART_Handle handle, void *buf, size_t count)
{
    // turn off green led to to indicate we sent uart data
    GPIO_write(Board_GPIO_LED1, Board_GPIO_LED_OFF);
    // start another UART read now that we have sent
    UART_read(handle, rxBuf, wantedRxBytes);
}

/*
 *  ======== mainThread ========
 */
void *mainThread(void *arg0)
{

    const char  echoPrompt[] = "Echoing characters:\r\n";
    UART_Handle uart;
    UART_Params uartParams;

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

    /* Create a UART with data processing off. */
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY;
    uartParams.readReturnMode = UART_RETURN_NEWLINE;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.baudRate = 115200;
    uartParams.readMode = UART_MODE_CALLBACK;
    uartParams.writeMode = UART_MODE_CALLBACK;
    uartParams.readCallback = readCallback;
    uartParams.writeCallback = uartWriteCallbackFxn;
    uartParams.readTimeout = 1000; // have tried various values from 10 to 1000000

    uart = UART_open(Board_UART0, &uartParams);

    if (uart == NULL) {
        /* UART_open() failed */
        while (1);
    }
    UART_control(uart, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL);  // if this line is uncommented, you never get UART data
    UART_write(uart, echoPrompt, sizeof(echoPrompt));

    int rxBytes = UART_read(uart, rxBuf, wantedRxBytes);

    /* Turn on user LED to indicate dropping into the while(1) */
    GPIO_write(Board_GPIO_LED0, Board_GPIO_LED_ON);


    while (1) {

    }
}

If that UART_control() call is in there, I will never receive any data. If I comment it out it works, but not as partial.

Nevermind, and thanks for your help. I found my problem with the partial and feel kinda dumb. It's the test in the read callback comparing size and wantedBytes. Obviously I was never going to call UART_write() on a partial with it like that.

Glad it worked out, happy to help!

http://dev.ti.com/tirex is indeed a good place to find the SDK documentation. You should be able to find the same documentations if you open the documentation overview HTML inside the 'docs' folder in your local SDK installation folder.