Odroid-C4 Hardware Setup#
This page covers the physical bench setup: how the serial console is wired to the board, and how the board’s power is switched. Get this right before you try to boot anything — every mistake on this page produces a symptom that looks like a software problem.
The two USB devices#
Role |
Adapter we use |
Chip |
USB ID |
Baud |
|---|---|---|---|---|
Serial console |
DTECH USB-to-TTL Serial Adapter |
PL2303 |
|
115200 8N1 |
USB power relay |
LCUS-1 5V USB Relay Module |
CH340 |
|
9600 8N1 |
Attention
Always identify these by chip, never by /dev/ttyUSB number — the numbering changes across replug.
See Identify the USB devices by chip for the udev rule that gives them
stable names.
Serial console wiring#
The serial adapter connects to the Odroid-C4’s 40-pin GPIO header. Three leads, and only three:
Signal |
Adapter pin |
Odroid-C4 40-pin header |
|---|---|---|
Ground |
GND |
pin 6 (GND) |
Board → host |
RX |
pin 8 (TXD) |
Host → board |
TX |
pin 10 (RXD) |
Power |
VCC |
leave disconnected |
Three rules, each of which has a distinct failure signature:
TX and RX are crossed. The adapter’s TX goes to the board’s RX (pin 10), and the adapter’s RX goes to the board’s TX (pin 8). Wiring them straight-through gives you complete silence — no output at all. That is a different symptom from garbled output; if you are seeing garbage, your TX/RX are fine and you have a different problem.
Common ground is mandatory. The adapter’s GND must go to the board’s GND (pin 6). Without a shared reference the two ends disagree about what a logic level is, and you get intermittent nonsense.
3.3 V logic only. The Odroid-C4’s UART pins are 3.3 V. Do not use a 5 V TTL adapter — it can damage the SoC.
Leave the adapter’s VCC lead disconnected. The board is powered from its own supply through the relay, not from the serial adapter. Back-feeding 5 V into the board over the serial header while it is also powered from the barrel jack is a good way to get confusing behaviour.
Note
Pin numbering on the 40-pin header is the usual convention: pin 1 is the corner pin nearest the board edge, odd pins in one row and even pins in the other. Cross-check against the HardKernel Odroid-C4 pinout if you are unsure — a mis-count of one pin is the most common wiring error.
Power path#
5 V / 4 A supply ──▶ CH340 USB relay ──▶ Odroid-C4 power in
The relay lets a script power-cycle the board unattended, which is what makes the automated benchmark campaign possible. Control it at 9600 baud with two 4-byte commands:
printf '\xa0\x01\x01\xa2' > /dev/odroid-relay # ON
printf '\xa0\x01\x00\xa1' > /dev/odroid-relay # OFF
Attention
The power relay is a suspect whenever serial output is garbled. A relay that cannot deliver the board’s peak current will brown the board out as soon as u-boot spins up the CPU and initialises DDR, and the symptom is corrupted serial that gets worse as the boot proceeds — not a wiring or baud problem at all. If you hit this, bypass the relay and power the board directly from the supply to confirm. The full differential diagnosis is in Serial port continuously prints garbage.
Network#
The board TFTP-boots from the host over a wired link with static addresses on both ends — there
is no DHCP server on the bench network. Host is 10.42.0.1/24, board is 10.42.0.2/24. See
Host Setup.