• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 2563 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UART CTS & RTS are continually active even with not Tx or Rx transmissions

PATRICK OHARA
Genius 3205 points
Other Parts Discussed in Thread: CC2540

We're accessing an MCU from our CC2540 via UART. The MCU is a Hycon Tech part HY11P23. We've defined a Comm API between the parts, but the HY11P23 is basically a black box to us. We notice that the CTS & RTS lines are constantly active (shown below) even though we are rarely communicating across the Tx & Rx. We understood that our RTS line would go high only at such time as the buffer is full, which never happens. Can someone please explain why we're seeing this correlated RTS & CTS traffic.

  • 0
    TI__Mastermind 34660 points
    What software is running on the CC2540?
  • 0 in reply to Tim C
    Genius 3205 points

    Hi Tim,

    The SimpleBlePeripheral with some minor modifications. We're wondering if the CC2540 RTS line is simply mirroring the CTS line from the HY11P23 since they are sol highly correlated. Is there a circumstance where this could be the case? Or is the RTS line driven entirely by the buffer "fullness."

    Thanks,

    Patrick

  • 0 in reply to PATRICK OHARA
    TI__Mastermind 34660 points
    It depends entirely what you have set in software as this is software flow control. I'm not familiar with the HY11P23 but if you added a UART driver similar to the PM UART driver discussed here: processors.wiki.ti.com/.../SerialBLEbridge_V_1.4.1

    you should expect:

    MRDY
    The RTS line of the device designated as the UART master is referred to as the MRDY signal and the RTS of the other device is referred to as the SRDY signal. The device designated as the UART master must assert MRDY as soon as possible after detecting a new SRDY. Also, a UART master must assert MRDY and wait for SRDY before transmitting data on the UART. The master should try to detect as soon as possible that the UART is not busy, and then de-assert its MRDY which will begin the process for both sides to re-enter PM.
    After de-asserting MRDY, if the master detects that the slave has de-asserted SRDY and the UART is still not busy, then the master can safely re-enter PM.
    SRDY
    The device designated as the UART slave must assert SRDY as soon as possible after detecting a new MRDY. Also, a UART slave must assert SRDY and wait for MRDY before transmitting data on the UART. The slave should try to detect as soon as possible that the master has de-asserted MRDY while the UART is also not busy, and then de-assert its SRDY after detecting the aforementioned two conditions.
    After de-asserting SRDY, if the slave detects that the MRDY is still not asserted and the UART is still not busy, then the slave can safely re-enter PM.
    The condition may arise that the SRDY is (and has been) asserted and there is data pending TX and the MRDY is not asserted. The Master may be signaling that it is ready to or has already gone into PM (remember that the Master initiates the return to PM by unilaterally de-asserting its MRDY as soon as it has nothing left to send and the UART peripheral is not busy). So the onus is on the Slave to break this dead-lock and toggle its SRDY (de-assert and re-assert) in order to give a new edge detect to the Master which will then be required to assert MRDY.
  • 0 in reply to Tim C
    Genius 3205 points
    Thanks Tim, that helps. However I don't see where the Master/Slave role is selected. If the CC2540 is the master, how does the Hycon chip know that it's not the maser?
  • 0 in reply to PATRICK OHARA
    TI__Mastermind 34660 points
    The drivers, as currently implemented, will always make the CC2540 the master.
  • 0
    Genius 3205 points
    UPDATE:
    It turned out that the microprocessor that we have no control over was active with other peripherals. This caused the nominally 50% duty cycle on the CTS/RTS lines. We found that function calls and responses from the CC2450 to and from the processor were stopping all over each other. So we added code to wait for a high to low transition on the CTS line to send our commands. This resolved much of the interference.