RTOS/CC2640R2F: Disabling UART TX while UART RX is active

David Schiel

Part Number: CC2640R2F

Tool/software: TI-RTOS

Hello TI E2E Community!,

In one of our new products we've got a single wire UART communication setup: It recieves data directly into the URX pin (of the CC2640R2F) and transmits data by pulling the communication line low by a transistor which is controlled by the UTX pin (simplified). In this setup, a high signal at the UTX pin corresponds to a low signal transmitted, so the communication is inverted.

Our problem is, that if we enable the UART Interface, the UTX constantly outputs a high signal, which in our setup pulls the communication line constanly low.

A solution to our problem would be disabling the UART transmit while UART read is active. This could supposedly be done in the CTL Register (30h, CC13x0, CC26x0 SimpleLink™ Wireless MCU Technical Reference Manual, Page 1472). We looked at the TI-RTOS code and couldnt find any mentioning of the CTL Register.

In the CC26xx Driver Library mentioned here, we could easily change the registers and create a corresponding function, to disable/enable the UTX, but this library differs from the TI-RTOS one (since it's not designed to run with TI-RTOS natively).

Our question is: Did we overlook something in the TI-RTOS code, that would allow us to disable UTX (temporarily)? Or do we need to write our own function, that interacts with the CTL register? If so, do we need to change anything/pay attention to anything else in the TI-RTOS to be compatible with disabling the UTX?

And yes: We know a hardware solution would be easy/probably a better solution, but it is not a option in our current prototype.

Our source code for testing the UART communication is straight up the "examples/drivers/empty" project with UART echoing example shown in UART.h.

We are currently using TI-RTOS (simplelink_cc2640r2_sdk_1_40_00_45) and Code Composer Studio 8.

Best regards,

David

over 7 years ago

0 IUsedToBeARealPerson (M-W) over 7 years ago

TI__Guru 58425 points

Hi David,

I will have to look into the best way to do this and come back to you, one way of doing this would be playing with the PIN muxing inside the UART driver (UARTCC26XX.c). If you want to look into this before I get the chance to get back to you, have a look at the "writeTxFifoFlush" function as this do some PIN muxing magic when fluxing the TX FIFO.

I suspect you would like to do something similar so that you mux the TX pin to be a low level GPIO and then restore the TX pin again when needed.

0 David Schiel over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 40 points

Hello M-W,

thank you for your quick responce.

I had a look into the quite interessting "writeTxFifoFlush" function. I however did not manage get a usable result out of it yet ( I did not spend a large amount of time on it either ). I will however play around with it over the next few days, and if I get an usable result, I will post the solution.

Best regards,

David

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to David Schiel

TI__Guru 58425 points

You are welcome, it will be interesting to see what you come up with! Let me know if you have any more questions along the way.

0 David Schiel over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 40 points

I've managed to create a tested working solution, based on the "writeTxFifoFlush" function. It works, but it isn't fast enough to really keep up with our 500k Baudrate. We've meausured a responce time of about 237µs to 244µs.

My next question: Is there any code optimization left, that could improve our responce time to about half the time it now takes? If not, we're probably forced to change our transmition setup in our next prototype run.

Source Code:

void Kill_TRX(UART_Handle handle){

    UARTCC26XX_Object               *object;
    UARTCC26XX_HWAttrsV2 const     *hwAttrs;

    object = handle->object;
    hwAttrs = handle->hwAttrs;

    PIN_setOutputEnable(object->hPin, hwAttrs->txPin, 1);
    PIN_setOutputValue(object->hPin, hwAttrs->txPin, 0);

    PINCC26XX_setMux(object->hPin, hwAttrs->txPin, IOC_PORT_GPIO);
}

void Revive_TRX(UART_Handle handle){

    UARTCC26XX_Object               *object;
    UARTCC26XX_HWAttrsV2 const     *hwAttrs;

    object = handle->object;
    hwAttrs = handle->hwAttrs;

    PINCC26XX_setMux(object->hPin, hwAttrs->txPin, IOC_PORT_MCU_UART0_TX);
}

The routine to measure the delay was:

while(1){

  UART_read(uart, &input,10);
  Revive_TRX(object,hwAttrs);

  UART_write(uart, &input, 10);
  Kill_TRX(object,hwAttrs);

}

Best Regards,

David

PS: Technically my problem is solved, so should i mark this as 'resolved', or should I wait if there is another, better solution?

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to David Schiel

TI__Guru 58425 points

Hi David,

When you talk about responds time, is it the time between write to read? In this case you might want to look into the "startTxFifoEmptyClk" function as well. Per default, after a write is "done" (all bytes have been put into FIFO), there is a small delay to wait for the TX FIFO to actually be empty. This is at least 100us (even if there is nothing left in the FIFO). I could imagine you could optimize this for your application and get it to work.

Feel free to mark your solution as resolved (as it so far is the best solution you have), if a better one pops up you can just mark that post as well.

0 David Schiel over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 40 points

We were able to cut down the responce time by another 50µs. This is still too slow for our application, but we're currently testing a new hardware workaround to solve our problem.

Thank you M-W for your time and informations.

I'll mark this thread as resolved since I've managed to write a working code and were able to evaluate it's perfomance.

Best Regards,

David

Bluetooth®︎

Bluetooth forum

RTOS/CC2640R2F: Disabling UART TX while UART RX is active