CC2340R5-Q1: About Event Callback Function for UART Function

sjmizuta

Part Number: CC2340R5-Q1

Hello,

I am using the CC2340R5-Q1 and developing software with SDK version 9.14. Currently I am developing a product for a customer and implementing/verifying UART functionality. As part of abnormal-condition checks, I intentionally input malformed data and want to decide how the software should respond when the CC2340R5-Q1 detects an error. To do that I am investigating how the CC2340R5-Q1 detects UART errors. I have observed the following behavior:

When receiving UART data that has no stop bit, the event callback function is not called. Instead, the read callback function is invoked.
In the read callback function, the status is reported as normal/OK.

My questions are:

If malformed data (in this case data without a stop bit) is received, should the event callback function be called?
How can I detect this condition as an error in software?

void Isr_Uart_Rx(UART2_Handle handle, void *buf, size_t count, void *userArg, int_fast16_t status)
{

    GPIO_toggle(CONFIG_GPIO_DIO13);
    uart_status = status;
    UART2_read(uart2_handle, &uart2_buf[0], (size_t)5, NULL);
}

void Isr_Uart_Event(UART2_Handle handle, uint32_t event, uint32_t data, void *userArg)
{

    GPIO_toggle(CONFIG_GPIO_DIO0);
    uart_event = event;
    uart_event_data = data;
}


void Uart_Setup(void) 
{
    UART2_Params uart2_params;

    UART2_Params_init(&uart2_params);
    uart2_params.readMode = UART2_Mode_CALLBACK;
    uart2_params.readCallback = Isr_Uart_Rx;
    uart2_params.readReturnMode = UART2_ReadReturnMode_PARTIAL;
    uart2_params.eventCallback = Isr_Uart_Event;
    uart2_params.eventMask = UART2_EVENT_FRAMING | UART2_EVENT_PARITY | UART2_EVENT_BREAK | UART2_EVENT_OVERRUN;
    uart2_params.baudRate = 500000;
    uart2_handle = UART2_open(CONFIG_UART2_0, &uart2_params);
    UART2_read(uart2_handle, &uart2_buf[0], (size_t)5, NULL);
}

I will attach the code I checked and the oscilloscope waveform for your reference.Thank you for yourhelp.

3 months ago

0 Josh Alderson 3 months ago

TI__Prodigy 640 points

Hello,

I am currently looking into this and will give an answer as soon as I can.

Thank you for your patience.

Best,
Josh Alderson

0 Josh Alderson 3 months ago

TI__Prodigy 640 points

Hello,

Yes, the way your code is written the event callback should be called for framing error according to the API design, but due to a limitation in the UART driver that interrupt does not currently work.

The RX callback is trigged due to an RX timeout event so yes this is expected behavior.

To detect this error, I would suggest creating your own error checking in the RX callback.
You can check the UART register error status using the API UARTGetRxError. This will return the error status in the UART_O_RSR_ECR register. The possible values this can return are listed in uart.h.

doing this will allow you to handle the error as you want.

A brief example is,

#include <ti/devices/DeviceFamily.h>

#include DeviceFamily_constructPath(driverlib/uart.h)

UART2LPF3_HWAttrs const *hwAttrs = handle->hwAttrs;

uint32_t errStatus;

errStatus = UARTGetRxError(hwAttrs->baseAddr);

if (errStatus != 0)

{

/* Error detected - determine type */

if (errStatus & UART_RXERROR_FRAMING)

{

/* Framing error detected (missing stop bit) */

uart_event = UART2_EVENT_FRAMING;

GPIO_toggle(CONFIG_GPIO_DIO0); /* Indicate error detected */

}

if (errStatus & UART_RXERROR_PARITY)

{

uart_event = UART2_EVENT_PARITY;

}

if (errStatus & UART_RXERROR_BREAK)

{

uart_event = UART2_EVENT_BREAK;

}

/* Clear the errors */

UARTClearRxError(hwAttrs->baseAddr);

/* Handle the error condition */

/* ... your error handling code ... */

}

Try something like that and please let me know if it works.

Best,
Josh Alderson

0 sjmizuta 3 months ago in reply to Josh Alderson

Intellectual 415 points

Hi Josh,

Thank you. Following your instructions and making the code changes you suggested, I was able to detect the abnormal status and identify the error details inside the read callback function. However, I have two questions to confirm:

I understand that the receive event callback currently does not run. Is it expected that this callback remains non-functional even though it is documented in the API reference?
Does the transmit event callback also fail to operate in the same way?

I appreciate your continued help.

+1 Josh Alderson 3 months ago in reply to sjmizuta

TI__Prodigy 640 points

Hello,

1. No, this seems to be a limitation within the SDK. The receive error event
   callbacks for framing errors (UART2_EVENT_FRAMING), parity errors
   (UART2_EVENT_PARITY), and break errors (UART2_EVENT_BREAK) do not currently
   trigger because the required hardware interrupts are not enabled in the driver.
   Note that UART2_EVENT_OVERRUN does work correctly. Thank you for bringing
   this to my attention. I will raise this issue with the driver team.

2. No, the transmit event callbacks (UART2_EVENT_TX_BEGIN and UART2_EVENT_TX_FINISHED) work correctly.

I would suggest using the workaround (polling UARTGetRxError() in your read

callback) for now, as any driver changes would be in a future SDK release.

Best,

Josh Alderson

Bluetooth®︎

Bluetooth forum

CC2340R5-Q1: About Event Callback Function for UART Function