1
\$\begingroup\$

Have a 16550 UART serial port on an embedded CPU based computer. It is not used in this fielded environment, however, it is possible that someone could attempt to connect to it and send data.

Need to ensure that any data sent to it, has no impact whatsoever.

Is having no driver sufficient and/or necessary to "closing" a port?

Will the default settings on the 16550 UART chip itself still gather data, if it receives anything on the line?

...or is there a more proper way to do this? For example, some setting on the UART itself...or in the program that executes on the rest of the board?

Thanks.

\$\endgroup\$
  • 1
    \$\begingroup\$ What embedded computer is this? I would assume that ignoring the hardware peripheral would prevent it from being used for communication so long as the code you want to run on the device is running correctly. \$\endgroup\$ – user2943160 Jul 8 '16 at 23:49
  • \$\begingroup\$ This is not answerable in its present form. To rule out the operation of the port, you would have to rule out any path that could result in executing code which attempted to configure or read it, or else electrically disable it. \$\endgroup\$ – Chris Stratton Jul 9 '16 at 2:02
5
\$\begingroup\$

An external 16550 UART, like this one, performs a conversion of the UART's serial data to and from parallel ports that can be read by a microprocessor/microcontroller. It is addressed as any external parallel I/O port, and has control registers for setting various modes, another for baud rate, another for status, one as a receive (Rx) buffer, and one for a transmit (Tx) buffer. (The Rx and Tx buffers may be tied through FIFO's, but that's the immaterial to this question. There are also other types of UART's that are accessed over I2C or SPI busses; that also has no bearing on the question.)

For received characters to have any effect on the microprocessor, a driver must be running that is responding to the UART. In addition, there must be a higher level of firmware that is communicating with the driver.

If you are running "bare metal", without an OS, then without code that explicitly writes to the registers in the UART to enable it for receiving data, nothing will happen. Even if the UART and receiver functionality is enabled, still nothing will happen except the character(s) will show up in the Rx buffer, and depending on the how the program is setup, the driver may or may not receive characters in an interrupt routine, where they will usually put into a internal software FIFO buffer. If there is no firmware to retrieve these characters, the buffer will just wrap around and overwrite itself.

If you are running on an OS, then you probably have to open the UART port to enable any receiving of data. Ports are almost never opened without explicit calls to the OS to do so. Even if this was done, if there is no firmware to handle the incoming characters, they will just be thrown away as the FIFO overflow. Nothing bad will happen, except that if characters are arriving at a very fast rate, then the UART interrupt handler will be getting called on every character and this will have some effect on your processor load. So it is best not to have the UART port open.

The only possible issue would be if the firmware both enabled the UART, and then enabled receive interrupts, and no interrupt handler was provided. Then when a character was received, the program would go off into never-never land. But this won't happen by itself, it would require the firmware to explicitly set things up to fail in this way. It would obviously be a serious bug to enable the UART and its interrupt capability and then not provide a handler.

\$\endgroup\$
  • 1
    \$\begingroup\$ Sounds like it might be a SBC to me, and not a microcontroller dev board. There may be an OS to deal with \$\endgroup\$ – Scott Seidman Jul 9 '16 at 0:09
  • 1
    \$\begingroup\$ @ScottSeidman Thx, I modified my answer. \$\endgroup\$ – tcrosley Jul 9 '16 at 0:30
  • \$\begingroup\$ @tcrosley: Thank you this is very informative and answers the question. \$\endgroup\$ – Greg McNulty Jul 26 '16 at 23:56
1
\$\begingroup\$

You have a few options:

  1. Leave the port as it is. In micro controllers, you need to enable the UART module before you can read or send data through it.

  2. Ground the RX pin of the module. If any data arrives, it won't enter the module. This should be sufficient if you are confident no one would bother modding the PCB to cut it off from ground.

  3. If you are still not satisfied, in the code, enable the module. Read the data, and do nothing with it. Just keep clearing the RX buffer whenever the data arrives.

It would be good if you could tell us exactly what you are doing, and what hardware you are using there.

\$\endgroup\$

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.