UART Interview Questions

Q1. What is UART and how does it transmit data?

UART (Universal Asynchronous Receiver-Transmitter) is an asynchronous serial protocol that transmits data bit-by-bit over a single wire per direction (TX and RX), framed with a start bit, 5–9 data bits, optional parity bit, and 1 or 2 stop bits — no separate clock line, so both ends must agree on the same baud rate in advance. A STM32F4 USART2 configured for 115200 baud, 8N1 transmits each byte as: 1 start bit (low) + 8 data bits (LSB first) + 1 stop bit (high) in 10 bit-periods = 10 / 115200 ≈ 86.8 µs per byte. UART is the most widely used protocol for debug consoles, GPS module interfacing (e.g., NEO-M8N at 9600 baud), and bootloader communication in embedded systems.

Follow-up: Why does UART send the least significant bit (LSB) first, and what would happen if receiver and transmitter disagree on bit order?

Q2. How do you calculate the baud rate error for a UART at a given MCU clock?

Baud rate is set by dividing the peripheral clock by the baud rate divisor register (BRR on STM32): BRR = f_clk / baud_rate; the actual baud rate is f_clk / BRR_integer, so the error is (actual - desired) / desired × 100%. For STM32F4 with APB1 = 42 MHz and target 115200 baud: BRR = 42000000 / 115200 = 364.58, rounded to 365 — actual baud = 42M/365 = 115068 baud, error = (115068-115200)/115200 = -0.115%. UART tolerance is typically ±2% (combined TX and RX error budget of ±4%), so an error below 0.5% per device is safe for reliable communication.

Follow-up: What is the maximum allowable baud rate error between UART transmitter and receiver and how is it derived from the sampling method?

Q3. What is the UART framing error and when does it occur?

A framing error occurs when the receiver samples the expected stop bit position and finds a logic low (0) instead of the expected logic high (1), indicating that the transmitter and receiver clocks are misaligned or the baud rates differ. In a GPS module (NEO-M8N) sending NMEA sentences at 9600 baud to an STM32 USART1 set at 9600 baud with 0.3% clock error, framing errors are absent; but if the STM32 clock is mis-configured to 8640 baud, framing errors appear because the receiver samples bit-center positions shifted progressively until the stop bit is sampled in the last data bit period. UART framing errors are detected via the FE (Frame Error) flag in USARTx_SR on STM32 and are the first thing to check when garbage characters appear at the receiver.

Follow-up: How do you distinguish between a baud rate mismatch and electrical noise as the cause of UART framing errors?

Q4. What is the difference between UART and USART?

UART (Universal Asynchronous Receiver-Transmitter) supports only asynchronous communication without a clock signal; USART (Universal Synchronous-Asynchronous Receiver-Transmitter) adds a clock line (CK pin) and can also operate in synchronous mode where the master provides a clock to the slave for half-duplex synchronous serial communication. STM32F4 peripherals labeled USART1–USART6 can operate in both modes; the CK pin is enabled in USART_CR2 for synchronous use. In practice, USART peripherals are almost always used in asynchronous (UART) mode because SPI provides better synchronous full-duplex performance, but the clock output is occasionally used for smartcard (ISO 7816) interfaces.

Follow-up: What is the smartcard mode in USART and what is its practical application in embedded systems?

Q5. What is hardware flow control in UART and when is it required?

Hardware flow control uses two additional signals — RTS (Request To Send, output) and CTS (Clear To Send, input) — to prevent buffer overflow: the transmitter checks CTS before sending each character and the receiver deasserts RTS when its buffer is nearly full. A cellular modem (SIM7600) connected to an STM32 via UART at 921600 baud requires RTS/CTS flow control because the modem can burst data faster than the STM32 DMA buffer can process it in a multitask firmware. Without flow control at high baud rates, overrun errors occur when a new byte arrives before the previous one is read from the receive data register.

Follow-up: What is the UART overrun error and how is it different from a framing error?

Q6. How do you implement UART receive using interrupts instead of polling?

Interrupt-driven UART receive configures the RXNE (Receive Data Register Not Empty) interrupt in USARTx_CR1, enabling NVIC for that USART; each received byte triggers the ISR which reads USARTx_DR (clearing RXNE), stores the byte in a circular ring buffer, and returns — the main loop consumes from the buffer when processing is needed. On STM32F4 with HAL, HAL_UART_Receive_IT() arms one interrupt-driven receive of N bytes, calling HAL_UART_RxCpltCallback() when done; for continuous streaming (GPS NMEA), a custom ring buffer ISR is more practical. The interrupt latency of ~12 cycles at 168 MHz (714 ns) is far shorter than the bit period at 115200 baud (8.68 µs), ensuring no bytes are missed.

Follow-up: What is the risk of reading UART data directly in the ISR versus using a ring buffer, and when does it matter?

Q7. How do you configure UART with DMA on STM32?

DMA-based UART transmit on STM32 configures a DMA stream linked to USART_DR as the destination, sets the source to the transmit buffer in SRAM, enables DMA transfer complete interrupt, then calls HAL_UART_Transmit_DMA() — the DMA engine transfers bytes to USART_DR autonomously without CPU involvement. For STM32F4 USART1 TX, DMA2 Stream 7 Channel 4 is the fixed mapping; configuring any other stream for this peripheral causes a hardware error. DMA-based receive with IDLE line detection (enabling UART_IT_IDLE) allows variable-length packet reception: the IDLE interrupt fires when the bus is quiet for one frame after a burst, telling the firmware exactly how many bytes arrived without polling.

Follow-up: What is UART IDLE line detection and how is it used for variable-length packet reception?

Q8. What is the UART baud rate when used for debugging and what are common standard rates?

115200 baud is the de-facto standard for debug UART consoles in embedded systems, outputting about 11,500 characters per second — enough for printf-style debug output without slowing real-time code noticeably. Common standard baud rates are 9600 (legacy sensors, GPS at default), 38400, 57600, 115200 (debug), 230400, 460800, 921600 (high-speed modem interfaces). Non-standard rates like 1 Mbaud are used in UART-based servo controllers (Dynamixel AX-12) and some BLDC motor ESCs where minimizing protocol latency matters more than using standard silicon.

Follow-up: What is the maximum practical UART baud rate on a typical STM32 at 72 MHz and what limits it?

Q9. What is UART parity and what does 8N1 mean?

UART parity is an optional error detection bit appended after the data bits — even parity sets the parity bit so the total number of 1s (data + parity) is even; odd parity ensures an odd count. 8N1 means 8 data bits, No parity, 1 stop bit — the most common UART configuration, transmitting each byte in 10 bit-periods total. Parity detects single-bit errors but not burst errors or double-bit errors; in practice, most embedded applications use 8N1 without parity and rely on application-layer CRC (e.g., Modbus CRC-16) for reliable error detection on noisy industrial communication lines.

Follow-up: What types of errors does UART parity fail to detect and what is a more robust alternative?

Q10. What is RS-232 and how does it differ from TTL UART?

RS-232 uses ±3 to ±15 V signaling with logic 1 = negative voltage (≤ -3 V) and logic 0 = positive voltage (≥ +3 V), while TTL UART uses 0–3.3 V or 0–5 V with standard positive logic. A PC DB9 serial port is RS-232 at ±12 V; connecting it directly to a 3.3 V STM32 UART will damage the MCU immediately — a MAX3232 or SP3232 level converter is required to convert RS-232 ±12 V to 3.3 V CMOS levels. RS-232 allows cable lengths up to 15 m at 115200 baud; for longer distances in industrial settings, RS-485 (differential, up to 1200 m at 100 kbaud) is the correct standard.

Follow-up: What is the difference between RS-232, RS-485, and RS-422 in terms of topology and cable length?

Q11. How is Modbus RTU implemented over UART?

Modbus RTU is a master-slave protocol where a master sends a framed request (device address + function code + data + CRC-16) over RS-485 UART at 9600–115200 baud, and the addressed slave responds after a turnaround delay of at least 3.5 character times. On an STM32F103 connected to a Siemens variable-frequency drive via RS-485 at 19200 8E1, a 6-byte Modbus RTU read request is transmitted by enabling the RS-485 DE pin high, sending the frame, then switching DE low within one half-character period to allow the slave to respond. Modbus RTU is the dominant fieldbus in Indian industrial automation — PLCs, drives, energy meters, and flow meters almost universally support it.

Follow-up: What is the 3.5 character time inter-frame gap in Modbus RTU and how do you implement it in firmware?

Q12. What is the UART receive overrun error and how do you prevent it?

An overrun error (ORE flag in USART_SR) occurs when a new byte arrives in the shift register before the firmware has read the previous byte from the receive data register (RDR), causing the new byte to be lost. On STM32F4 at 921600 baud, each byte arrives every 10.8 µs; if an ISR or DMA handler takes longer than this to service the UART, overruns occur. Preventive measures include using DMA receive to eliminate software latency entirely, increasing receive buffer depth, reducing interrupt latency, and for critical systems, reducing baud rate — choosing 460800 gives 21.7 µs per byte, doubling the firmware margin.

Follow-up: Does clearing the ORE flag alone recover the UART, or is additional action needed?

Q13. What is the difference between full duplex and half duplex UART operation?

Full duplex UART uses separate TX and RX wires, allowing simultaneous transmission and reception; half duplex uses a single wire for both directions (or the TX connected back to RX), with the firmware controlling when to transmit versus receive using a direction-control signal. RS-485 is inherently half duplex — an STM32 drives the DE/RE pins of a MAX485 to switch the bus transceiver between transmit and receive mode, with a guard time of at least one bit period between direction switch and first transmitted bit. Half duplex is used in bus topologies where multiple nodes share one line, while full duplex is used in point-to-point links where two wires are available.

Follow-up: What is the loopback test mode in UART and how is it used for self-diagnostics?

Q14. What is the LIN protocol and how does it relate to UART?

LIN (Local Interconnect Network) is a single-wire master-slave serial protocol built on top of UART framing at 1–20 kbaud, used in automotive body electronics for low-cost, low-speed sensor and actuator networks where CAN is unnecessary. STM32F4 USART peripherals support LIN mode with a break detection circuit that recognizes the 13-bit dominant break field that starts each LIN frame. In a car door module, window switches, mirror motors, and courtesy lights communicate over LIN to a master BCM (Body Control Module) using LIN frames at 10.4 kbaud — a typical car has 15–20 LIN slaves per cluster.

Follow-up: What is the LIN break field and how does it synchronize nodes without a separate clock line?

Q15. How do you implement printf over UART on STM32?

Printf over UART is implemented by redirecting the C standard library _write() syscall (or fputc() for newlib nano) to write each character to the USART TX data register and wait for TXE (Transmit Data Register Empty) flag before each byte. On STM32CubeIDE with newlib nano, adding int _write(int fd, char *buf, int len) calling HAL_UART_Transmit() in retarget.c, and linking with -specs=nosys.specs, routes all printf() output to USART2 connected to the ST-LINK VCP. Blocking HAL_UART_Transmit printf is acceptable for debug builds but must be replaced with DMA or ITM/SWO trace for production firmware where printf latency would affect real-time behavior.

Follow-up: What is SWO (Serial Wire Output) ITM tracing and why is it preferred over UART printf for time-critical code?