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.

CC1352P: UART2_write() blocking for 200-500 us in UART2_Mode_NONBLOCKING

Part Number: CC1352P

Hi ! 

SDK 6.41.0.17 + syscfg 1.15.0 + CCS 12.3.0.00005

I'm moving data from the radio to the UART in a low priority RTOS task loop. 
I'm noticing, using a GPIO toggle and a scope to time it, that UART2_write() is blocking my thread for 200-500 us.

Can you tell me if I have this setup properly? is 200-500 us normal for the non blocking API ?

void appUartInit() {
    UART2_Params uartParams;
    UART2_Params_init(&uartParams);
    uartParams.baudRate = 8*115200;
    uartParams.writeMode = UART2_Mode_NONBLOCKING;
    uartParams.readMode = UART2_Mode_NONBLOCKING;
    /*
     * UART2_ReadReturnMode_PARTIAL unblocks or performs a callback whenever a read timeout error occurs on the UART peripheral.
     * This timeout error is not the same as the blocking read timeout in the UART2_Params;
     * the read timeout occurs if the read FIFO is non-empty and no new data has been received for a device/baudrate dependent number of clock cycles.
     * This mode can be used when the exact number of bytes to be read is not known.
     */
    uartParams.readReturnMode = UART2_ReadReturnMode_PARTIAL;

    uart[1] = UART2_open(CONFIG_UART_0, &uartParams);

    if (uart[1] == NULL)
    {
        while (1) {}
    }
}

int appUartWrite(uint8_t *buf, int len) {
    size_t bytesWritten = 0;
    GPIO_write(CONFIG_GPIO_0, 1);
    UART2_write(uart[1], buf, len, (size_t *)&bytesWritten);
    GPIO_write(CONFIG_GPIO_0, 0);
    return bytesWritten;
}

  • Hi Mike, 

    Your setup seems okay. 

    I checked the UART2.c source file in the SDK, it seems that the data is copied into the UART ring buffer and then it starts the DMA transfer is called. In the blocking mode, it waits for the DMA to complete the transfer, in non blocking it simply returns. So I think the time delay you see is the copy of this data into the ring buffer. So the delay depends on the number of bytes transferred.   

    You could check if running the call from higher priority helps. 

    Regards,

    Sid

  • Thanks Siddanth. 

    I noticed the same thing when I went thru the code. I'm transmitting 128 bytes. 

    I did notice it performs a bit better when I did not specify non blocking mode and left it in the default blocking mode. 
    I just used the params from Uart2_Params_init() and then changed only the baud rate. 

    I added some GPIO toggles and I noticed that my radio thread is actually interrupting 100 us of my time in Uart2_write(), so its really spending about 200-300 us of time in that function with a 100 us context switch in the middle. 

    I found the priorities didn't seem to affect the time spent in Uart2_write(), so I reverted all my tasks to the same priority as they were before I noticed this issue. Things seem stable and the timing of the system is dialed in. 

    With Non Blocking mode, I was seeing my radio thread get delayed causing timing jitter of when TX actually happens. 
    With Blocking mode, my radio thread does not get delayed, presumably because my TX is getting scheduled while the uart task is yielded while blocked in Uart2_write()