I send breaks (using Tx) over FTDI FT232R chipset using two ways:

a. Using the BREAK command in the operating system (Windows 7 and Ubuntu)
b. Gating the Tx line for an arbitrary period

I connected the Tx pin to the Rx pin of the FT232R (loopback test) and used a variety of serial consoles to read the Rx input

I always got a binary 0 in both case. Each case individually behaved so:

  • i. Using the BREAK command, I recieved binary 0 when the BREAK command was made active (BREAK is active low)
  • ii. When gating the Tx line, I recieved binary 0 when I forced the Tx line low

This does not seem right to me.

The only time when the UART Rx can get "confused" between BREAK and a binary 0 transmission, is when the BREAK switches the line low for exactly 9 bits duration and then brings the line back to high (making the Rx side misinterpret as a stop bit), but this breaks a definition of BREAK which requires the line to be held low for at-least 10 bits duration.

So my questions are:

  1. Is this expected behaviour ?
  2. If you do a loopback test on your FTDI chipsets can you reproduce this behavior (implying I have bad drivers/faulty chipset)

Yes, this is expected behavior. Most UARTs will interpret the start of a "break" condition as an all-zero (null) byte that happens to have a framing error (no stop bit). Some (but not all) UARTs also have hardware detection of "break", but this typically kicks in only if the break condition extends for more than two whole character times (i.e., >20 bit times).

Traditionally, a hardware UART makes all bytes received available to the software; in other words, anything that can be interpreted as a start bit will cause a byte to be delivered to the software — along with status bits indicating possible parity and/or framing (stop bit) errors. It's up to the software to discard bytes that have errors, if that's the desired behavior.

I don't know about the FT232R specifically; it may be one of those UARTs that simply doesn't care about framing errors and has no way of signaling them to the USB host.

  • \$\begingroup\$ That's right, I was expecting "framing error" but not a "here is a 0 for you". Also, how would the Receiver signal there has been an error, to me? I looked here (ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf) and found no details on how to detect such an error in the driver \$\endgroup\$ – vsmGuy Dec 19 '12 at 19:57
  • \$\begingroup\$ How is a byte with a framing error a "valid" byte? \$\endgroup\$ – vsmGuy Dec 19 '12 at 19:59
  • 2
    \$\begingroup\$ Depends on if the software checks the status bits... Problem here is that you have at least four layers - the UART, the firmware, the driver, and the operating system serial API. Details can get lost at any level, particularly when packaging into a buffer to send over the USB. \$\endgroup\$ – Chris Stratton Dec 19 '12 at 20:02
  • \$\begingroup\$ @ChrisStratton: True, but I was asking specifically about support of detecting the error from the FTDI chipset itself. \$\endgroup\$ – vsmGuy Dec 19 '12 at 20:04
  • \$\begingroup\$ And I was answering about the FTDI chipset - there are all of those layers involved when using it, the last two of which you potentially have control over. \$\endgroup\$ – Chris Stratton Dec 19 '12 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.