CC3220SF-LAUNCHXL: uart2echo_CC3220SF_LAUNCHXL_tirtos_ccs runs in exception handler if uart rx line is permantly pulled low at baudrate 921600

Arnaud Moeschwitzer

Hello,

i am facing a problem with the uart 2 driver. If i am setting baudrate to 921600 and pulling rx line permanent low on LAUNCH-cc3220-modasf a exception handler is thrown. See picture:

It only happens if am using baudrate = 921600 at 115200 it won't happen.

My used SOP-Configuratuion is 000. I used the ground from j21.

Why is that happen, is it a bug in the sdk driver ?

My SDK Configuration is shown above.

BR,

Arnaud

over 2 years ago

0 Roman Jordan over 2 years ago

Expert 1770 points

Hello Arnaud,

I inspected your issue with the SDK 5.10.0.02 and got the same wrong behavior.

Using:

the SimpleLink SDK 5.10.0.02
the Launchpad for the CC3220MODASF
a fixed Low-Level at the Rx-Pin of the UART connected to the XDS
a configured baudrate of 921600

The call UART2_open while the listed conditions are set results in the indefinitely spin you captured.

Btw. the baudrate of 460800 "seems" to work well.

Best regards,
Roman

0 Sarah P over 2 years ago in reply to Roman Jordan

TI__Mastermind 38980 points

Hi Arnaud, Roman,

I'm seeing this issue on any pin that is not connected to a UART device (i.e. baud rate 921600 always works when the pin is connected to the XDS110). The fault occurs when the UART driver tries to construct the HwiP. Please give me a day or two to investigate further.

Best regards,

Sarah

0 Roman Jordan over 2 years ago in reply to Sarah P

Expert 1770 points

Hello Sarah,

I inspected only the RX pin of the UART. Setting the baudrate to 115200 and forcing the RX pin to ground at the initialization time of the UART doesn't result in an error.

If the ground connection of the RX line is removed after the mentioned UART initialization it is working in the usually way.

Best regards,
Roman

0 Roman Jordan over 2 years ago in reply to Sarah P

Expert 1770 points

Sarah P said:
I'm seeing this issue on any pin that is not connected to a UART device

Hello Sarah,

I didn't understand your sentance. Can you please explain it to me?

Best regards,
Roman

0 Sarah P over 2 years ago in reply to Roman Jordan

TI__Mastermind 38980 points

Hi Roman, Arnaud,

I meant to say that I also see the issue whenever the UART2 Rx pin is left floating.

The issue does not occur when the Rx pin is tied to 3V3. My assumption is there is a race condition occurring at high baud rates where the UART2 Rx interrupt is triggering before the driver is fully initialized, causing the fault. I can file a bug for this.

I see no such issue on the other UART driver. Can you use the UART driver in the meantime? (Note that the UART and UART2 drivers use the same underlying hardware peripheral, but are different implementations, aka like "UART version 2.0". You can create multiple instances of either the UART or UART2 drivers.)

Best regards,

Sarah

0 Roman Jordan over 2 years ago in reply to Sarah P

Expert 1770 points

Hello,

thanks for explanation. I inspected the same behavior. If the pin is left floating it is also at low level and becaus of that it shows the same behavior.

Currently I decide to use the lower baudrate of 115200 for the UART2. Until now I didn't see any problems using UART2, 115200 baud and a floating RX line (or fixed ground level).

I also know about the both UART configurations/ templates.
Does there exist a documentation about that both UART variants?
Why there (still) exist two variants?
I was thinking UART2 is the newer design and because of this I prefered the UART2.

Best regards,
Roman

0 Arnaud Moeschwitzer over 2 years ago in reply to Sarah P

Intellectual 785 points

Hi Sarah,

for my application uart2 fits better than uart. So maybe sdk should get fixed.

BR,

Arnaud

0 Sarah P over 2 years ago in reply to Arnaud Moeschwitzer

TI__Mastermind 38980 points

Hi Arnaud, Roman,

UART2 is newer, but both drivers were kept for legacy purposes. The differences are documented in the UART2 TI Drivers API documentation found here or in the SDK.

I have filed a bug for the issue, but it will take some time to be added to our release cycle. I do not have a committed date at this time.

I have found a potential solution is disabling the hardware peripheral interrupt before creating the HwiP, and then initializng the hardware at the end of UART2_open(). This is similar to the other UART driver. You can add the file source/ti/drivers/uart2/UART2CC32XX.c directly to your project, which applies the changes without having to rebuild the library. You can try this solution, but please note that this has not been tested yet.

    /* DMA first */
    UDMACC32XX_init();
    object->udmaHandle = UDMACC32XX_open();
    if (object->udmaHandle == NULL) {
        UART2_close(handle);
        return (NULL);
    }

    /* !! Change !! */
    /* Disable the UART interrupt. */
    MAP_UARTIntDisable(hwAttrs->baseAddr,
                      (UART_INT_TX | UART_INT_RX | UART_INT_RT));

    HwiP_clearInterrupt(hwAttrs->intNum);

    HwiP_Params_init(&hwiParams);
    hwiParams.arg = (uintptr_t)handle;
    hwiParams.priority = hwAttrs->intPriority;
    HwiP_construct(&(object->hwi), hwAttrs->intNum, UART2CC32XX_hwiIntFxn,
            &hwiParams);

    SemaphoreP_constructBinary(&(object->readSem), 0);
    SemaphoreP_constructBinary(&(object->writeSem), 0);

    /* Timeout clocks for reads and writes */
    ClockP_Params_init(&(clkParams));
    clkParams.arg = (uintptr_t)handle;

    ClockP_construct(&(object->readTimeoutClk),
            (ClockP_Fxn)&UART2CC32XX_readTimeout,  0 /* timeout */,
            &(clkParams));

    ClockP_construct(&(object->writeTimeoutClk),
            (ClockP_Fxn)&UART2CC32XX_writeTimeout,  0 /* timeout */,
            &(clkParams));

    /* !! Change !! */
    /* Initialize the hardware */
    UART2CC32XX_initHw(handle);

    return (handle);

Best regards,

Sarah

Wi-Fi

Wi-Fi forum

CC3220SF-LAUNCHXL: uart2echo_CC3220SF_LAUNCHXL_tirtos_ccs runs in exception handler if uart rx line is permantly pulled low at baudrate 921600