CC2642R: Using UART2 driver for RTS/CTS pin control to get to half duplex RS485?

Marc Yaxley

Part Number: CC2642R
Other Parts Discussed in Thread: SYSCONFIG

I've been beating around the bush on this one. I know the MCU h/w has a UART which can do RTS/CTS pin control, it's in 'SYSCONFIG' pages.

However it seems to not work and one can only set FLOWCONTROL on and then define both CTS and RTS pins in SYSCONFIG.

What I need is for RTS to drop low to switch my RS485 line driver IC to output or input as needed. I am currently doing this with

simple GPIO_write() to a pin and having a small delay before and longer one after switching this line. This is really a task for the H/W UART

do do since it 'knows' when it wants to send a buffered character out the TX pin. I'd like it to do that after setting RTS and ignoring the CTS

pin as it's not needed and nothing to connect it to any way.

Having walked through the UART source code and stepped through it I don't see a whole bunch of user configuration other than to say I want

flow-control and here are the two pins to use in the SYSCONFIG pin editor.

What isn't clear from the CC26x2R1F H/W data book is just what the RTSEN and RTS pins do or when they are set/reset by the H/W.

I know RTSEN enables the function, but the RTS bit in that register states that it seems to 'invert' what the 'RTS signal' would be and I guess

it means that's what gets presented on the MCU pin? So that register bit is just a way to invert the internal RTS signal for the UART?

The implication is that the 'RTS signal' is some internal value which usually drops LO to request to send and the RTS register pin simply

inverts this signal as it would present on the MCU pin?

What if my description is true or right?

Does TI engineers have any source code examples of using this with either the driver library modules or directly to the H/W registers?

What you have is pretty confusing and easy to mess up by changing the library source files which I'm trying to avoid. I would suspect

somebody in TI's library development team would have coded the UART2 library and may have some routines.

I also see there are two events which might help me: (from UART2.H)

/*!
* @brief The UART will start transmitting data.
*
* This event can be useful in RS-485 half-duplex systems to toggle TX enable high.
*/
#define UART2_EVENT_TX_BEGIN (0x10)

/*!
* @brief The UART stopped transmitting data.
*
* This event can be useful in RS-485 half-duplex systems to toggle TX enable low.
*/
#define UART2_EVENT_TX_FINISHED (0x20)

These two events seem to be available in an 'event callback' which isn't documented to well in the SDK pages. I found

it's source code doc's are much newer than the on line fancy pages. This seems to be the call/doc to use for them:

/*!
* @brief      The definition of a callback function used by the UART driver.
*              The callback can occur in task or interrupt context.
*
* @param[in] UART2_Handle            UART2_Handle
*
* @param[in] event                   UART2_EVENT that has occurred.
*
* @param[in] data                    - UART2_EVENT_OVERRUN: accumulated count
*                                      - UART2_EVENT_BREAK: unused
*                                      - UART2_EVENT_PARITY: unused
*                                      - UART2_EVENT_FRAMING: unused
*                                      - UART2_EVENT_TX_BEGIN: unused
*                                      - UART2_EVENT_TX_FINISHED: unused
*
* @param[in] userArg                 A user supplied argument specified
*                                      in UART2_Params.
*
* @param[in] status                  A UART2_STATUS code indicating
*                                      success or failure of the transfer.
*/
typedef void (*UART2_EventCallback)(UART2_Handle handle, uint32_t event, uint32_t data, void *userArg);

Found in: /ti/simplelink_cc13xx_cc26xx_sdk_6_30_01_03/source/ti/drivers/UART2.h

I guess I could use this method, but some of the things I find in TI's libraries are not working, work strange or are

harder than hell to understand, code up and then debug. Can anyone attest that UART Events actually work?

I could set/reset my RS485 signal with these two events occurring and not have to have inline program delays this way.

I hope I'm not to wordy here, but I wanted to fully explain my experience in trying to do half-duplex RS485 with the SDK.

Thanks for any help or recommendation,

Marc

PS, I'm using the CC2642R1F part.

over 2 years ago

0 Marc Yaxley over 2 years ago

Expert 1105 points

Update: I coded an example using UART2_EVENT_TX_BEGIN and UART2_EVENT_TX_FINISHED defines as events. I do get

a call back with each of these. But moving my modbus direction setting to these does not work. What is not clear with out using

a Oscope is when these two event actually occur after doing UART2_write( mbuart, &c, 1, NULL ); which sends 1 char. out.

It would be nice if the driver for UART2 had details on this in the documentation. Poking around in the source code is slow going

and somewhat guess work as to how the eventCalback actually works. Let alone the timing of these events in relation to the

UART actually shifting out the character data.

0 Ryan Brown1 over 2 years ago

TI__Guru**** 211997 points

Hi Marc,

Here are direct links to the TRM and UART2.h TI Driver reference. Hardware flow control is detailed in Section 21.4.4.2.1 of the TRM:

Hardware flow control between two devices is accomplished by connecting the UART0RTS output to the ClearTo-Send input on the receiving device, and connecting the Request-To-Send output on the receiving device to the UART0CTS input. The UART0CTS input controls the transmitter. The transmitter can transmit data only when the UART0CTS input is asserted. The UART0RTS output signal indicates the state of the receive FIFO. UART0CTS remains asserted until the preprogrammed watermark level is reached, indicating that the RX FIFO has no space to store additional characters.

Also in the FR and CRL Register Descriptions:

Clear To Send: This bit is the complement of the active-low UART CTS input pin. That is, the bit is 1 when CTS input pin is LOW.
Request to Send This bit is the complement of the active-low UART RTS output. That is, when the bit is programmed to a 1 then RTS output on the pins is LOW.

If you review <sdk_directory>\source\ti\drivers\uart2\UART2CC26X2.c you will find that UART2_EVENT_TX_BEGIN and UART2_EVENT_TX_FINISHED are passed to the callback during UART2Support_dmaStartTx and UART2CC26X2_hwiIntFxn, respectively, which does imply the the UART2.h documentation should be updated. You can add UART2CC26X2.c directly to your project workspace in order to debug this file instead of using the pre-built TI Driver library, this would confirm the state of UART activity when the event flags are set. Of course, a logic analyzer or oscilloscope would greatly assist in the investigation as well.

Regards,
Ryan

0 Marc Yaxley over 2 years ago in reply to Ryan Brown1

Expert 1105 points

Thank you for the reply. I have found that section of code you mention where UART2_EVENT_TX_BEGIN and UART2_EVENT_TX_FINISHED are called from the driver to produce the events. The problem I am seeing is from that TX_BEGIN until the UART actually shifts data out is unknown as by the time my code responds to the event and gets the direction bit set one or more characters might have gone out to nowhere since my direction bit is not set yet. Also this only works in the write polling mode, which is fine. I had to find all this out by inspecting the driver source code. The SDK doc's for this are lacking.

I think the best idea is to snag the write polling source code to my own build and simply put my GPIO calls in to set direction rather than generate the events and hope the timing works with that method. Good thing is I only need 19200 baud so its not pushing things to much.

As you say the hardware RTS/CTS bits in the actual UART core if enabled do not allow the transmitter to send if CTS isn't asserted. I don't have this bit but the RTS may or may not assert, I couldn't make it so far. Confusing that one can leave CTSEN disabled but enable RTSEN, in which case what does the UART hardware do? Still need CTS to transmit or not? A question for the chip designer team I guess. Some data books I've used in the past have great diagrams of the internal h/w subsections and how register settings apply. The data book for this chip is huge but does not include block diagrams for the old hat simple UART as such, but in fact it is still there with the flow control state-machine working in some unknown specifics not shown to us programmers.

Anyway I'm seeing a couple of ways to do this with out using delay timing loops around sending TX data out the UART.

Thanks again,

Marc Y.

Bluetooth®︎

Bluetooth forum

CC2642R: Using UART2 driver for RTS/CTS pin control to get to half duplex RS485?