I've looked through a few related posts on the forum and tried to find some specifics on the expected RTS/CTS behavior in UART mode on the CC2480. The datasheet (or interface spec, I can't remember) specifies that RTS and CTS are mandatory, but neither outlines the details of their operation. Can someone point me to a waveform or a step-by-step outline of a transmission on the part of both the host processor and the CC2480? e.g.,
1. X sets (logic 1) RTS.
2. Y sets (logic 1) CTS when ready.
3. X begins transmission of data.
and so on...
My 2480s will send SYS_RESET_IND, but they don't respond to any commands from my host processor, and I think it may be due to RTS?CTS behavior. Are these signals, in fact, mandatory? Is there a way to bypass them and have no hardware flow control? I can do either, but I have to emulate the flow control in software, and I don't know what the 2480 expects.
Thanks for the help.
The cc2480 interface spec has an error in the direction of the uart flow control pins. The correct information for the CC2480 uart mode is
P16 RTS Output
P15 CTS Input
Note that the terms RTS and CTS are used here while considering the CC2480 as a DCE equipment ( since it is usually the slave to a host processor ).
So LPRF's presentation in this thread is exactly backward in terms of RTS/CTS direction?
I appreciate the response, but I still don't think my question has been answered. What is the specific sequence on which pins of the CC2480 that I should use to initiate communication with the CC2480 from my host processor? At this point the CC2480 will not respond to any of my input, and I am trying to debug hardware and software at the same time. It would be helpful if I knew that what I was doing in software was correct.
Unfortunately that presentation must have been following the datasheet and thats why the pin mapping is reversed in the presentation.
where it says “A non-standard symmetrical alternative is widely used: CTS indicates permission from the DCE for the DTE to transmit, and RTS indicates permission from the DTE for the DCE to transmit. The "request to transmit" is implicit and continuous”
Also from: http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html#anchor1179408
Pin 4 - Request to Send (RTS) This signal is asserted (logic '0', positive voltage) to prepare the DCE device for accepting transmitted data from the DTE device. Such preparation might include enabling the receive circuits, or setting up the channel direction in half-duplex applications. When the DCE is ready, it acknowledges by asserting Clear to Send.
Pin 5 - Clear to Send (CTS) This signal is asserted (logic '0', positive voltage) by the DCE device to inform the DTE device that transmission may begin. RTS and CTS are commonly used as handshaking signals to moderate the flow of data into the DCE device.
Then from the 2430 datasheet (CC2480 uart behaves the same way):
22.214.171.124 UART Hardware Flow Control
Hardware flow control is enabled when the
UxUCR.FLOW bit is set to 1. The RTS output
will then be driven low when the receive
register is empty and reception is enabled.
Transmission of a byte will not occur before
the CTS input go low.
Which jives with the above definitions of DCE and DTE.
I guess this whole definition of DCE/DTE can be confusing… maybe we should not use that terminology and just stick with the language used in the CC2430 datasheet.
With all this being said, I would just use rx and tx for now and not even worry about RTS/CTS so that you can get some confidence that you have basic communication working.Cheers,
So I guess to summarize (when flow control is used - from the perspective of the host micro):
When the host wants to send something to the CC2480, it must see that the RTS pin is low.When the host wants to receive something from the CC2480, it must drive the CTS pin low. Note: The ZASA application on the MSP430 does not use flow control (just rx tx)
Excellent. I'll give this a shot.
So, contrary to the specifications, RTS and CTS are not mandatory based on your recommendations here? Can I just leave them floating to get the basic communication working, or should I tie them to something?
What I'm seeing right now is that if I leave RTS/CTS floating, the CC2480 boots up, transmits a short message (SYS_RESET_IND), and then doesn't respond to anything sent from the host processor. I've used a logic analyzer as well as listening in on the transmissions from the host with a PC-based terminal and it looks like the data being transmitted to the CC2480 is correct, but the device doesn't act on the commands. I assume that if I see SYS_RESET_IND that the CC2480 can be assumed to be more-or-less operating correctly?
Part of the confusion, I think, in terms of the RTS/CTS operation is that there are multiple standards for the behavior of these pins depending on the system. I have looked at the CC2430 datasheets before and have worked with the 2430, but I don't think it's appropriate to ask someone to refer to a specification for a different part to know how this one operates. The remainder of the confusion, to me, is what constitutes a logic 1/0 in terms of the CC2480 behavior. I would expect logic 1 to be a positive voltage (3V or 5V) on a chip like this and logic 0 to be 0V. Given that the RS232 standards for TX/RX lines have a somewhat inverted convention for logic 1/0 makes it ambiguous as to whether or not the RTS/CTS lines would follow the more obvious (TTL or CMOS) conventions or the RS232-style convention.
I appreciate the help. I'll go work on this some more and see if I can get it figured out.
If you can see the SYS_RESET_IND it's basically a good sign. Judging from the 2480 target board ref design the RTS and CTS pins are floating so you should be ok to leave them floating. However, what is important is driving the CFG0 and CFG1 pins to a known state at startup (select UART mode and no 32kHZ mode (unless you have one on your board)).In terms of how this part operates, logic 0 = 0V, logic 1 = nominally 3V. The best thing to do after receiving the SYS_RESET_IND is to send down a read configuration command to see if the 2480 responds.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.