Using a Serial Console for Embedded Firmware Debugging

When the screen is dark and the network is down, the UART console is often the only thing that can tell you what the board is doing.

For embedded work the serial console is the lowest-level channel that almost always comes up before anything else. Whether it is a bare microcontroller printing boot messages or a Linux board dumping its kernel log, the UART is the first place to look when a device will not behave.

This article covers the practical side of attaching a console: voltage levels, wiring, the boot window, and how to read what the board tells you before higher-level debugging tools can run.

Voltage levels before wiring

Modern boards almost always use logic-level UART, typically 3.3 V, not the +/-12 V of classic RS-232. Connecting a 3.3 V board directly to an RS-232 port can damage it, so a logic-level USB-to-serial adapter is the usual bridge.

Confirm the board's expected level and whether its TX/RX are already routed through a level shifter. Some boards expose a dedicated console header with GND, TX, and RX clearly marked; others hide it among general GPIO that must be configured at boot.

Wiring the three lines

The console needs ground plus the board's TX (its output) and RX (its input). The cross-over rule is the common stumbling point: the adapter's RX connects to the board's TX, and the adapter's TX connects to the board's RX. Ground connects to ground.

Do not connect the board's power to the adapter's power unless the design explicitly intends it; a separate, known-good power supply for the board avoids back-feeding through the console cable.

• GND to GND. The reference both sides need.
• Adapter RX to board TX. You receive the board's output.
• Adapter TX to board RX. You send input to the board.
• Leave power alone unless the header is designed to supply it.

Catching the boot window

Many boards print a prompt during early boot that lets you interrupt the bootloader, and that window can be brief. Open the terminal and set the port before applying power, or press the reset while the console is already streaming, so you do not miss the prompt.

For Linux targets the kernel and init output flow through the same console. A hang during boot shows exactly where it stopped, which is far more useful than a silent, unresponsive device with no other diagnosis path.

Reading MCU vs Linux output

A microcontroller console tends to print application or RTOS messages at a fixed baud the firmware sets, often 8N1. A Linux board prints U-Boot or equivalent, then the kernel, then a getty login, usually at a baud set by the device tree or boot arguments.

If you see garbage at the expected baud, recheck the frame format and the level shifter before assuming the firmware is broken. A logic-level mismatch produces the same unreadable stream as a baud mismatch.

Making the console repeatable

Save the working baud and wiring as a named profile so the next debug session starts connected, not reconfiguring. Note the board revision and header pinout alongside it, because the console pins move between hardware revisions more often than people expect.

For field returns, capturing the full boot log to a file turns a vague 'it does not boot' into a specific failure line that hardware and firmware can act on without the board in front of them.

The console is the first layer, not the only one. When a board hangs before it prints anything, or the UART is silent, a debugger probe such as SWD or JTAG reaches the core directly and shows where execution stopped. Treat the console and the probe as complementary: the console explains software behavior, the probe explains why the software never started.

Bridge the laptop with a USB-to-serial adapter, fix unreadable output, then capture the boot log with timestamps so the failure is documented.

Common questions

Can I connect a 3.3 V board straight to an RS-232 port?

No. Classic RS-232 uses much higher voltages that can damage logic-level UART pins. Use a logic-level USB-to-serial adapter matched to the board's voltage.

Why do I see nothing on the console?

Check the three connections first: GND, adapter RX to board TX, adapter TX to board RX. Also confirm baud, data bits, parity, and stop bits match what the firmware uses, and that you opened the port before or during boot.

What baud should I use for a Linux board?

It depends on the board and its boot configuration; common defaults exist but the device tree or boot arguments set it. Check the board documentation rather than assuming a single rate.

Why is my console output garbled?

A garbled stream usually means a baud or frame-format mismatch, or a voltage-level problem. Recheck settings and the level shifter before blaming the firmware.

How do I not miss the bootloader prompt?

Open and configure the terminal before applying power, or trigger a reset while the console is already streaming. The interrupt window can be short, so being connected ahead of time is the reliable approach.

Keep reading