8

Looking for some assistance testing a UART implementation with hardware flow contorl for the OMAP L138. To test the implementation I use minicom to emulate the other end of the serial link and I'm looking for some insight into how it needs to be configured.

I have a simple application that sends messages over UART from the OMAP to minicom. This works as expected if both OMAP and minicom are configured to NOT use hardware flow control. When I turn hardware flow control on, I don't see any output on minicom.

Here's the list of steps I followed:

  • Configured minicom to use hardware flow control (Ctl A-O to open minicom serial port setup menu, and F to enable hardware flow control).
  • Using stty I enable rts/cts handshaking stty -F /dev/ttyS1 crtscts. Using the command stty -F /dev/ttyS1 -a I can confirm that crtscts has been enabled.

The two changes above ensure that hardware flow control is enabled in the terminal program and in the UART driver. The UART on the OMAP has also been configured to use hardware flow control.

However, the changes to minicom listed above don't seem to be sufficient to get flow control to work correctly. After starting the application, the RTS(request to send) signal from the OMAP goes low, indicating to minicom that it wants to send data. If configured properly minicom should pull the OMAP's CTS(clear to send) signal low and start accepting data until it reaches the specified receive buffer threshold. This does not happen. The CTS input to the OMAP is always high. Just for kicks, I tried shorting the RTS to CTS on the OMAP and voila, the expected messages do show up on minicom! Here's an image that shows how the two are hooked up.

Omap to minicom connections

From what I've tried it seems like I'm missing something in the way I configured minicom. Any suggestions appreciated.

dinesh
  • 705
  • 2
  • 8
  • 20
  • Is there a question in there somewhere? – Dan May 24 '13 at 06:42
  • See if you can set the PC's CTS line low using stty. If so it's a problem with minicom, if not it's a driver/hardware problem (you could even have a cable without enough wires). You may want to write your own program anyway, as it may be difficult to get minicom to ever signal unready - on a modern PC you'd likely need a program which intentionally neglected to read() in a timely manner. – Chris Stratton May 24 '13 at 14:05
  • Just send Stop signal like `kill -STOP $(pidof minicom)`. To continue, use `CONT`. – Turbo J May 24 '13 at 16:48
  • @Dan This was more...here's what I've tried so far...does everything look ok :) – dinesh May 28 '13 at 19:27
  • @Chris Stratton Good tip about the cables. In my case the cable wasn't the issue but in my very next test I did run into a cable that did not have CTS/RTS wired. Probably saved me a day's worth of debugging :) – dinesh May 28 '13 at 19:31
  • Following up on the tip from @ChrisStratton I checked the connection and discovered that the RS232 to TTL adapter boards did not have CTS and RTS wired but brought them out to jumpers on the board. After connecting the jumpers everything works as expected. – dinesh May 29 '13 at 21:04

0 Answers0