• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 254 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

RTOS/LAUNCHXL-CC2640R2: UART hardware flow control - RTS changes to LOW after setting port id

LAUNCHXL-CC2640R2: Keeping RTS high when RX is disabled

Laur Joost
Prodigy 250 points
Part Number: LAUNCHXL-CC2640R2
Other Parts Discussed in Thread: CC2640

Hi!

Trying to use HW flow control. Somewhat miffed with the HW flow control behaviour.

Currently, if flow control is enabled, then RTS is set low ("Accepting incoming data") as soon as UART_open() is called. This, however, is utter lies, as in reality, the peripheral is only ready to receive data when UART_read() has been called, and will automatically disable reading on many occasions: Timeout, break, etc. On all of these occasions, RTS will remain low, and the other party will happily send data into the void without anyone the wiser.

Also, this means that to receive URC-s (Unsolicited responses, i.e. I don't know when they will come) from an AT modem, I bloody well HAVE to keep the CC2640 out of standby (By keeping it "reading"), as there's no way to signal to the modem that "I'm not accepting data right now, wait until I'm ready" (aka: flow control).


Is modifying the driver to disable RTS flow control on disableRX and enabling it again on enableRX the only way to make it behave? Am I missing a better way to acieve low power AND ability to receive random messages?

I can't use the "wakeup on dummy byte" solution, as I don't control the protocol, and the wakeup time of the CC2640 (according to the datasheet at least) is on the order of char lengths at 115200 baud.

  • 0
    TI__Guru 57865 points

    Hi Laur,

    I understand your frustration. However, in order to maintain low power in such architecture (with serial connection). I believe you will need to either use a dummy command or an interrupt to wake-up and prep CC2640R2 for incoming serial messages. 

  • 0 in reply to J Lindh
    Prodigy 250 points

    It's perfectly possible, if both sides honor flow control (RTR/CTS flow control in this case): Just do intermittent reception, the other side, if it wants to say something, will wait until you're ready to receive. Of course, periodic wakeup is not ideal, but at 100:1 duty cycle, and given that the standby power draw of the GSM modem is ~1 mA, pulling that of the CC2640 down from contributing another milliamp is a win.

    As I said, I don't control the protocol, it is as uBlox has implemented it. And in fact, there isn't a signal in RS-232 that means "DCE wants to send to DTE" anyway.

    The hardware flow control could do this better, but that's workaroundable. What I'm mostly frustrated about is that the TI driver doesn't easily let me fake it.

    Meh, that's what register access is for, I guess.