Vision board UART no output at low baud: raise to 19200

You have a compact vision board on the bench, a program that opens Serial1 at 9600 baud, and a logic analyzer clipped to two pins. The GPIO pin toggles high and low every loop, so the code is running. The pin labeled UART_TX sits flat at logic high and never moves. Before touching the wiring, read the number inside Serial1.begin(): this board family's UART does not output at 9600 baud, so that rate produces a line that looks dead. This guide gives the rate that fixes it, the analyzer test that separates a rate floor from a pin-mapping fault, and the wiring checks that keep the port alive once it reaches a PLC, HMI or PC.

Why does UART TX stay flat at 9600 baud while the GPIO toggle beside it works?

Because the port was opened at 9600 baud, which sits below the floor this board's UART peripheral has: the transmitter never starts, so the TX line holds idle-high while the GPIO toggle runs beside it.

The program is structurally sound, and that is what makes the symptom confusing. pinMode and digitalWrite drive the pad directly, so the toggle appears on schedule. Serial1.print hands bytes to the UART peripheral, and the peripheral rejects the configuration: no start bit, no edges, nothing for the analyzer to decode. The vendor's one-line support answer for this exact symptom is to use a rate at or above the family minimum.

Note the signature, because it splits two different problems. An unsupported rate gives silence: a perfectly flat, idle-high line. A supported but mismatched rate gives bursts that decode as garbage. Silence means the transmitter is off; garbage means the two ends disagree.

What is the lowest baud rate this UART will actually output?

19200 baud is the floor: the vendor's guidance for this board family is that rate or higher, and at 9600 baud the peripheral produces no output at all on the TX pin.

A UART generates its rate by dividing a peripheral clock, and every clock frequency supports only a band of rates; chip manuals print those bands as baud tables with a minimum and a maximum per clock. On this board, 9600 baud falls below the band the core will program. In practice, the floor plus 38400, 57600 and 115200 baud all work, while 9600, 4800 and 2400 give a silent line.

The floor applies to the physical UART pins, not to a USB virtual COM port, which ignores the baud number and carries data at USB speed. The floor is about the peripheral, not reliability: there is nothing to gain below it, because the port will not run there at all.

How do you prove the fault is the rate, not the wiring?

Toggle a GPIO in the same loop and watch both pins: a toggling GPIO with a flat TX at 9600 baud, then frames on TX at the working rate with no other change, proves the rate floor - same code, same pads, same ground.

Change one number at a time and let the toggle confirm the loop between reprograms:

1. Leave the GPIO toggle (pin 10, PE_13) exactly as it is; it proves the program runs after every reprogram.
2. Set the analyzer to at least 1 MS/s and probe UART_TX (PA_9) together with a board GND; at 1 MS/s you get about eight samples per bit even at 115200 baud.
3. Capture with Serial1.begin(9600): the toggle blinks every 100 ms while the TX trace never leaves logic high.
4. Change only the rate, reprogram, recapture.
5. Add the analyzer's UART decoder at the rate you just set, 8N1, and read the text back.

int pinIO = 10;    // PE_13: the heartbeat pin
int Counter = 0;   // loop counter, starts at zero

void setup() {
  Serial1.begin(19200);        // 9600 leaves TX silent on this board
  pinMode(pinIO, OUTPUT);
  digitalWrite(pinIO, HIGH);
  Serial1.println("Hello World!");
  digitalWrite(pinIO, LOW);
}

void loop() {
  delay(100);
  digitalWrite(pinIO, HIGH);
  Serial1.print("Count: ");
  Serial1.println(Counter++);
  digitalWrite(pinIO, LOW);
}

Everything except the argument to Serial1.begin() is the failing program. With the family minimum in place, each byte shows a start bit, eight data bits and a stop bit. Clamp the board so both probes stay seated across reprograms: the LS-MNT-0006, a portable optical test stand, holds it at a working angle while you iterate.

If the toggle stops after the change, the reprogram failed or the program crashed; fix that before judging the UART.

How fast is the floor rate in real bytes?

At the floor rate with 8N1 framing you get 1920 bytes per second, one 10-bit frame every 0.52 ms, which is plenty for status lines and counters.

Work the two lines this program sends. The startup message "Hello World!" plus its two line-ending bytes is 14 bytes, or 140 bits: 140 / 19200 = 0.00729 s, about 7.3 ms on the wire. Each loop line "Count: 0" plus two ending bytes is 10 bytes, or 100 bits: 100 / 19200 = 5.2 ms, inside the 100 ms window that delay(100) sets, with roughly nineteen times headroom. At 115200 baud the same loop line takes 100 / 115200 = 0.87 ms, and the port tops out at 11520 bytes per second.

That is the whole budget decision. A board that sends one line per 100 ms cycle uses about five percent of a link running at the floor, at its busiest moment, so the slow rate costs nothing.

Which baud rate should you run: the floor, 115200 or something between?

Run the floor rate for short status lines to a PLC or HMI, and 115200 baud when the board logs or streams text: both sit inside this family's supported range, and 115200 baud carries 11520 bytes per second at 8N1.

Two rules keep the link alive. Both ends carry the same number - a mismatch between board and host produces garbage, never an error message. And treat 115200 baud as the practical ceiling on this class of board: some embedded vision stacks stop exactly there, and faster rates need the peripheral clock behind them. Above roughly 11.5 kB per second, move the data to Ethernet or USB instead of pushing the UART.

How do you take the UART off the board to a PLC, HMI or PC?

Bring out TX, RX and GND on the board side through an open-lead cable, land the far end on the host's serial connector, and put a level shifter between TTL and any RS-232 port - three connections, never two.

On the board side, power and I/O cables with open ends give you solderable cores: put board TX, RX and GND on their own cores and keep the rest for power or future signals.

On the host side, a PC or PLC COM port takes a DB9F-to-open cable: screw the shell to the port and land the same signals on its open leads.

Ground the link properly: a serial line without a shared ground shows the same flat trace as a dead one. The external trigger timeout: wrong pin or wrong ground guide works through that failure on a trigger input, and the fix there - one common ground point - is the same fix here.

Plan the host side before the cable goes in: wiring a barcode scanner to an HMI serial port covers the handshake checks that apply to any serial device on that port, and remember that a host which never transmits will see nothing back until it polls. When the controller has no free port, reading a barcode reader through the HMI is the pattern that saves the project.

If software on the vision host is the only consumer, skip serial entirely: setting the camera timestamp over USB3 Vision instead of UART lines shows why the USB link is the right channel for timing data.

Why is the TX line still silent after raising the rate?

Work down this order: the pin name in the program, a TX and RX swap at the connector, a shared pad claimed by another driver, then the analyzer's own ground - pin mapping beats the rest in practice.

1. Wrong pin mapping. The pad the core drives is not the pad under your probe. Headers get relabeled and cores remap pads between firmware builds. Test: probe every candidate pad while the loop runs. The smart camera UART pin mapping guide works this exact fault class, and camera IO board pin alignment shows how to lock the pinout before anything is mounted.
2. TX and RX swapped. RX idles high too, so a swapped probe looks identical to a dead line. Test: move the probe to the neighboring pad and recapture.
3. Another driver claimed the pad. A camera or sensor stack in the same program can reassign the pad after setup(). Test: comment out that driver's initialization and recapture; the camera shield shared IO pins guide lists the overlaps to check first.
4. Missing common ground. Without a shared ground the analyzer trace floats or stays flat. Test: clip analyzer GND to board GND; it is the cheapest fix on this list.
5. All prints inside setup(). If every Serial1.print sits in setup() and the port comes up late, one burst can slip past you. Test: print from the loop, as the program above does.

What should you check before ordering the breakout cable?

Check four things: the board's pin map, the logic level at the host port, the baud rate both ends will share, and the mechanical path the cable takes - in that order, before anything goes on order.

• Pin map: which pad carries UART TX on your firmware build; label the analyzer capture with it.
• Logic level: TTL at the board, RS-232 at a COM port; order the converter with the cable, not after.
• Rate and format: the family minimum on this board, 8N1 at both ends, one number written into both programs.
• Cable route: a moving axis or drag chain needs a drag-chain-rated lead; a fixed cabinet run is easier on any cable.
• Ground: one common point for board, host and analyzer.

Then pull the lead from the accessories finder, check it beside your camera and light in the system configurator at the extras step, and if the host port is fixed by the controller, bring its format to the contact page and we will match the lead to it. More bench bring-up fixes sit under the systems topic.