If your ArmSoM board shows a black screen, repeatedly restarts, or cannot boot into the operating system, capture a serial log starting from power-on. It helps technical support identify which stage of startup is failing.
The essential sequence: keep the board powered off → connect the debug UART → open the serial terminal and enable logging → power on the board.
Running dmesg after Linux starts cannot recover earlier DDR initialization or U-Boot serial output.
1. What you need
- Your ArmSoM board and a separate power supply that meets its specifications.
- A USB-to-TTL UART adapter with logic levels matching the board’s debug UART.
- Jumper wires and a host computer.
- PuTTY on Windows, or minicom on Linux.
Make sure both the adapter and its driver support 1500000 baud. A USB connection alone does not guarantee this.
The debug interface uses TTL UART: do not connect it directly to an RS-232 port. Check the UART voltage in the board schematic before wiring. For a board with 3.3 V UART signals, use a 3.3 V logic-level adapter. On some adapters, the “3.3 V / 5 V” jumper changes only the power output, not the TX signal level.
2. Find the correct debug UART
The following connections are documented for Sige7/5/3/1 and CM5 with the official CM5-IO carrier board:
| Board physical pin | Connect to the USB-to-TTL adapter |
|---|---|
| Pin 6: GND | GND |
| Pin 8: TX | RX |
| Pin 10: RX | TX |
These are physical header pin numbers, not GPIO numbers. Cross TX and RX.
Wire the board with its power disconnected. Connect only GND, TX and RX; use the board’s normal power input and leave the adapter’s VCC disconnected.
For receive-only logging, you can start with just board TX → adapter RX, plus GND. This prevents the computer from sending characters to the board. Connect board RX when interactive input is needed.
Check the official diagrams for the connector location and pin 1 orientation:
Do not apply this pin mapping automatically to other boards, third-party carriers, or custom carriers. For CM5, the carrier board determines where the debug UART is exposed. Follow that carrier’s documentation or schematic.
3. Configure the serial connection
ArmSoM documents the following default settings for its Rockchip-based products:
| Setting | Value |
|---|---|
| Baud rate | 1500000 |
| Data bits | 8 |
| Parity | None |
| Stop bits | 1 |
| Hardware flow control | None / off |
| Software flow control | None / off |
In short: 1500000 baud, 8N1, no flow control. See the official serial setup instructions.
Custom firmware may use different settings. If output becomes unreadable at a particular stage, check the DDR firmware, U-Boot and Linux console configurations separately.
4. Windows: capture a log with PuTTY
Identify the COM port
Connect the USB-to-TTL adapter to your computer, keeping the board powered off.
In Windows Device Manager, expand Ports (COM & LPT) and note the adapter’s port, such as COM5. Unplugging and reconnecting the adapter can help identify it. If no port appears, install the manufacturer’s driver for your adapter.
Configure the session and log file
Open PuTTY:
- Under Session, select Serial.
- Set Serial line to your port, for example
COM5. - Set Speed to
1500000. - Under Connection → Serial, select 8 data bits, 1 stop bit, None for parity, and None for flow control.
- Under Session → Logging, select All session output.
- Set Log file name to a new file in a writable folder, for example
sige7-coldboot-01.log. - Click Open.
“All session output” records received terminal output. The resulting file may contain terminal control characters; that is normal. See the PuTTY logging documentation.
Power on and record
Only after the serial window is open, connect power to the board.
Let the board boot without pressing keys, which can interrupt U-Boot autoboot. Keep recording until a login prompt appears, the failure stops progress, or at least two restart cycles have been captured.
Close PuTTY, then open the log file. Check that it contains output and includes the earliest startup messages received. Submit the log file rather than screenshots or only the final few lines.
5. Linux: capture a log with minicom
Run these commands on the host computer connected to the UART adapter.
Install minicom on Debian/Ubuntu:
sudo apt install minicom
Find the adapter:
ls -l /dev/serial/by-id/
The example below uses /dev/ttyUSB0; replace it with your actual device path.
Open the configuration menu:
sudo minicom -s
Under Serial port setup, configure:
- Serial Device: your adapter’s device path.
- Bps/Par/Bits:
1500000 8N1. - Hardware Flow Control: No.
- Software Flow Control: No.
Save the configuration as armsom and exit. Start a session with logging enabled from the beginning:
sudo minicom -o -D /dev/ttyUSB0 -b 1500000 \
-C armsom-coldboot-01.log armsom
Once the terminal is open, power on the board. When finished, press Ctrl+A, then X, and confirm exit. Check armsom-coldboot-01.log in the current directory.
-C opens the capture file at startup; -o skips modem initialization. Do not run another serial tool on the same device at the same time. See the minicom manual.
6. Recognize the boot stages
A typical Rockchip startup can be understood as:
BootROM → DDR initialization / early loader → U-Boot → Linux kernel → userspace
The exact sequence and output depend on the chip and firmware.
| Log clue | What it helps identify |
|---|---|
| DDR, memory type, frequency or training information | Early firmware is initializing memory |
| U-Boot identification and storage-loading messages | The bootloader is finding or loading the system |
Starting kernel |
The bootloader is handing control to the kernel |
Linux version or kernel timestamps |
The kernel has started producing output |
| Service startup messages or a login prompt | Userspace has started |
These are clues, not fixed text guaranteed to appear in every image. BootROM may not produce readable serial output either.
Missing DDR messages do not by themselves prove a DDR failure. Rockchip DDR firmware supports UART selection, baud-rate configuration and disabling training-information output. Some images therefore omit these messages. See the Rockchip DDR binary configuration guide.
7. Troubleshooting the capture
| Symptom | Check first |
|---|---|
| No output at all | Correct COM/device path, board power, common ground, board TX connected to adapter RX, and the correct debug UART |
| Garbled output throughout | Baud rate, 8N1, logic levels, and adapter/driver support for 1500000 baud |
| Readable output becomes garbled at one stage | Whether that stage changes the baud rate |
| Only Linux messages appear | Whether the terminal was opened after power-on; whether early firmware disables logging or uses a different UART |
| Output works but keyboard input does not | Board RX wiring, flow control, and whether the current stage supports interactive input |
| Startup messages repeatedly begin again | Preserve the complete cycles and provide power-supply and peripheral details for diagnosis |
Prefer a cold boot when collecting a log from power-on. If Linux is running, shut it down normally before disconnecting board power. Keep the host-side adapter, terminal and logging active, then reconnect the board’s power.
Whether a software reboot or reset button reruns DDR initialization depends on the platform and firmware; neither is guaranteed to behave exactly like a cold boot.
8. What to send to technical support
Attach the log and include:
Board model and hardware revision:
SoC model:
Carrier board model (for compute modules):
Image filename and download link, or SDK commit:
Boot storage:
Power supply and connected peripherals:
USB-to-TTL adapter model:
Serial settings:
Capture method: cold boot / reset / software reboot
Observed failure:
Boot log attachment:
Keep the complete recording from power-on through the failure. Mention any keys pressed, peripherals connected or disconnected, or manual resets during capture. Before sharing, check the log for personal information or credentials that need to be removed.