Troubleshooting

This guide covers common issues encountered with the Cruiser Carrier Board and their solutions.

Power Issues

Board won’t power on

Symptoms: No LEDs illuminate, no activity when pressing power button.

Solutions:

1. Verify power supply is connected and meets minimum voltage:
   • Cruiser/Cruiser Lite: 48V minimum
   • Cruiser Keel: 13V minimum
2. Check D2 (blue standby LED) - should be lit when power is connected
3. Press S0 (power button) on the board
4. Check CM5 seating - reseat the compute module once. See Reseating the compute module before repeating it.

Which LEDs are lit narrows this down quickly. See Reading the board LEDs for what each stage tells you: the blue LED reports the board’s own 5V rail, while the yellow and green LEDs depend on the compute module.

Reseating the compute module

The compute module sits on two fine-pitch board-to-board connectors, and those connectors have a finite mate life. Every removal and refit spends part of it. Worn or displaced contacts produce exactly the intermittent symptoms that prompt reseating in the first place, so repeated reseating can manufacture the fault you are trying to clear.

Reseat once. Power off, unplug the supply, lift the module evenly, check both the module and board connectors for bent or missing contacts under good light, and refit with even pressure on both connectors.

If one reseat does not fix it, stop and contact support@exaviz.com rather than repeating the cycle. Tell us how many times the module has been removed over its life. That number changes what we look at, and it is not recoverable once the board is in front of someone else.

Power button won’t turn the board on (some HDMI displays connected)

Symptoms: Pressing the power button does nothing when certain HDMI displays are connected, but the board still powers off normally. Reproduced with some displays but not others.

Solutions:

1. Disconnect the HDMI cable, press the power button to boot, then reconnect HDMI (hot-plug is detected normally)
2. Confirm 48V is present at the DC jack — power-off still works even when power-on is blocked by HDMI
3. See the J3 System Header note for the hardware cause (HDMI +5V supply path on the current board revision, display-dependent)

No PoE power to devices

Symptoms: Connected PoE devices don’t power on.

Solutions:

1. Verify input voltage is 48V minimum (required for PoE+)
2. Check port status: head -20 /dev/pse
3. Verify device is 802.3af/at compliant
4. Check total power budget isn’t exceeded

Boot Issues

Slow boot from USB flash drive (~45 second delay)

Symptoms: System takes 45-60 seconds to boot from a USB flash drive. You see the network link activate and DHCP requests going out before the OS finally starts loading from the USB drive.

Cause: This is a boot order timing issue, not a hardware problem. The USB flash drive needs 1-2 seconds after power-on for the USB subsystem to fully enumerate it. The default Raspberry Pi EEPROM boot order (e.g. 0xf2461) tries SD → NVMe → USB → Network. SD and NVMe fail almost instantly (~100ms each), so the bootloader reaches USB before the drive is ready. It moves on to Network boot, which takes 30-60 seconds to timeout (DHCP requests, link negotiation). After the timeout, the boot loop restarts and USB succeeds on the second pass.

You are effectively paying a ~45 second Network boot penalty because the USB drive needed an extra second or two to enumerate.

Fix: Set USB as the first boot device. The bootloader’s own initialization (loading EEPROM config, setting up clocks, etc.) provides enough time for the USB subsystem to be ready by the time it reaches the first boot mode check:

# Create config file
echo -e "[all]\nBOOT_UART=1\nBOOT_ORDER=0xf2614" | sudo tee /tmp/boot.conf

# Apply to EEPROM
sudo rpi-eeprom-config --apply /tmp/boot.conf

Boot order 0xf2614 decodes as (read right to left):

With USB first, the drive is already enumerated when the bootloader checks it, and the system boots immediately without ever reaching Network boot.

SD card boots from power-on but not after a reboot

Symptoms: On a CM5 Lite booting from a microSD card, a cold power-on boots normally but a warm reboot (sudo reboot) fails in one of two ways:

• The bootloader loops, printing SD TIMEOUT or FAT read failed.
• Linux starts, prints mmc0: Skipping voltage switch and then mmc0: error -110 whilst initialising SD card, waits, and drops to the BusyBox (initramfs) prompt with ALERT! PARTUUID=... does not exist.

Removing power for about 10 seconds always brings the board back.

Cause: The microSD slot stays powered for as long as the board has power, so a reboot does not power-cycle the card. Linux runs fast (UHS) cards with 1.8 V signalling. Under the SD specification, a card only leaves 1.8 V mode when its power is removed, so after a warm reboot the card is still in 1.8 V mode and cannot be initialized again.

Whether you see this depends on the card. In our testing, a Gigastone 8 GB card and a Samsung 128 GB card failed on warm reboot, while a Samsung 32 GB card rebooted cleanly.

Fix: Keep the card at 3.3 V signalling with a small device-tree overlay. The cost is speed: the card runs in SD high-speed mode (50 MHz) instead of UHS, and we measured about 24 MB/s reads in this mode. This fix is for a CM5 Lite booting from microSD only: on a CM5 with eMMC the same interface drives the eMMC, and the overlay would slow it down too.

If you are at the (initramfs) prompt, remove power for 10 seconds, let the board boot, then follow the steps below.

1. Save the following as sd-no-uhs.dts:

   /dts-v1/;
   /plugin/;
   / {
   	compatible = "brcm,bcm2712";
   	fragment@0 {
   		target = <&sdio1>;
   		__overlay__ {
   			no-1-8-v;
   		};
   	};
   };
   

2. Compile it and install it into the overlays directory. If dtc is not found, install it first with sudo apt install device-tree-compiler.

   dtc -@ -I dts -O dtb -o sd-no-uhs.dtbo sd-no-uhs.dts
   sudo cp sd-no-uhs.dtbo /boot/firmware/overlays/
   

3. Add this line to /boot/firmware/config.txt as the last line of the [all] section:

   dtoverlay=sd-no-uhs
   

   Do not just append it to the end of the file. The [cm5] and [cm5l] sections are rewritten when the Exaviz driver package updates, which would remove the line. If there is no [all] line, add one above [cm5].

4. Shut down, remove power for 10 seconds, then power on. This first restart must be a real power-off, not a reboot, because the card is still in 1.8 V mode.

5. Confirm the card is no longer in UHS mode:

   dmesg | grep "mmc0: new"
   

   The line should read mmc0: new high speed SDHC card (or SDXC card). If it says ultra high speed or UHS-I speed, or names a bus mode such as SDR50, SDR104 or DDR50, the overlay is not loaded.

In our testing, warm reboots then worked.

Alternative: If you would rather keep UHS speeds, power the board off and on instead of rebooting.

Storage Issues

NVMe not detected

Symptoms: NVMe drive doesn’t appear in lsblk or fdisk -l.

Solutions:

1. Verify drive is seated properly in M.2 slot
2. Check dmesg | grep nvme for errors
3. Ensure M.2 mounting screw is installed
4. Try a different NVMe drive to rule out drive failure

SATA drives not detected

Symptoms: SATA drives don’t appear in system.

Solutions:

1. Check SATA data cable connections
2. Verify Molex power connector is connected (J2)
3. Check dmesg | grep ata for errors
4. For RAID configuration, check DIP switch settings

Only one SATA port detects a drive

Symptoms: A known-good drive works on J11 (D14 lights) but the same drive and cable are not detected on J23. D15 stays dark and nothing new appears in lsblk. Swapping drives and cables changes nothing.

Check the RAID mode before assuming the port is faulty. The RAID mode is a property of the whole JMS561 controller, not of one port, and it changes how the ports present themselves to Linux. Only JBOD (both S3 switches OFF) presents two independent drives. In RAID 1 the controller presents a single logical volume at single-drive capacity, so the second drive is not exposed as its own device. A board set to RAID 0, RAID 1 or SPAN can therefore look exactly like a dead second port.

Read the switch positions against the table in Hardware Interface - RAID DIP Switch.

To tell a configuration problem from a real port fault, read the controller directly rather than relying on lsblk. With the known-good drive in J23 and nothing in J11 (see JMicron RAID Manager for installation):

sudo raidmgr_static
# At the JMS56X> prompt:
DC C0
SS C0
SR C0
EX

DC C0 and SS C0 list what the controller itself sees on each channel, as Sata[0] and Sata[1], with model name, serial number and capacity. This comes straight off the controller and does not depend on Linux enumerating a block device:

• The drive is listed on one of the channels - the port, its channel and the link are working. The RAID mode is the likely cause. Set the switches to JBOD using the full procedure and retest.
• Neither channel lists it, with a known-good drive and cable in J23 - this points to a genuine port or channel fault. Contact support.

SR C0 shows whether an array already exists, which matters because the DIP switches only configure a new array when no array is present. Delete an existing array with DR C0 R0 first, or the switch change will appear to do nothing.

Network Issues

2.5GbE WAN not working

Symptoms: WAN port doesn’t link up or shows poor performance.

Solutions:

1. Verify cable supports 2.5GbE (Cat5e minimum, Cat6 recommended)
2. Check link status: ethtool eth0
3. Try forcing speed: ethtool -s eth0 speed 1000 duplex full
4. Update RTL8156 firmware if available

Switch ports not working

Symptoms: 1GbE switch ports don’t establish link.

Solutions:

1. Check cable connections
2. Verify port status: ip link show
3. Check switch configuration in Exaviz software

Wireless Issues

WiFi not working

Symptoms: No wlan0 interface, can’t connect to WiFi.

See ESP32 Troubleshooting for detailed steps.

Quick checks:

1. dmesg | grep esp — Check ESP32 status
2. ip link show wlan0 — Verify interface exists
3. Reset the ESP32 if unresponsive

Bluetooth not working

Symptoms: Bluetooth devices won’t pair or connect.

Solutions:

1. Check ESP32 status: dmesg | grep esp
2. Verify Bluetooth service: systemctl status bluetooth
3. Scan for devices: bluetoothctl scan on
4. Reset the ESP32 if unresponsive

Video Issues

No HDMI output

Symptoms: Monitor shows no signal from HDMI port.

Solutions:

1. Reseat the CM5 once - improperly seated compute modules are a common cause of HDMI issues. Power off, remove the CM5, and reinstall ensuring proper alignment on both connectors. Read Reseating the compute module first: reseating is not free, and repeating it can create the fault you are chasing
2. Try the other HDMI port
3. Try a different HDMI cable
4. Verify monitor supports the resolution
5. Check vcgencmd get_config hdmi_group for settings

Logging and Diagnostics

No logs from before a reboot (“journalctl -b -1” is empty)

Symptoms: After rebooting a board to recover from a problem, there is no record of what happened. journalctl -b -1 returns nothing, and journalctl --list-boots only ever shows a single boot.

Cause: Raspberry Pi OS keeps the systemd journal in RAM only. It ships /usr/lib/systemd/journald.conf.d/40-rpi-volatile-storage.conf containing Storage=volatile, which discards all logs on every reboot. This is a Raspberry Pi OS default, not an Exaviz setting, and it protects SD cards from write wear.

The practical consequence is that rebooting a misbehaving board destroys the evidence of why it misbehaved — usually before anyone has collected it.

To confirm this is what you are seeing:

# shows the effective setting from all config locations
systemd-analyze cat-config systemd/journald.conf | grep -E '^Storage'

# /run/log/journal means RAM only; /var/log/journal means persistent
journalctl --header | grep 'File path'

Solution: Add a drop-in that sorts after the Raspberry Pi one:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-persistent-journal.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=200M
EOF

sudo systemctl restart systemd-journald
sudo journalctl --flush

Verify it took effect — this line should now appear, and it is absent when persistence is not working:

journalctl -b 0 -u systemd-journald | grep 'System Journal'
# System Journal (/var/log/journal/<machine-id>) is 8M, max 200M, 192M free

After the next reboot, journalctl --list-boots will list more than one boot.

Trade-off to weigh before enabling. Persistent logs mean additional writes to the boot media. On an SD card or USB flash drive that contributes to wear; on an SSD it is not a practical concern. The SystemMaxUse=200M cap bounds both the write volume and the disk space used, which matters on the small filesystems these boards typically run.

Our recommendation is to enable it, especially on any board you are actively diagnosing. Leaving it on means that when something does go wrong, the record already exists — whereas enabling it after an incident is too late to explain that incident.

To revert, delete /etc/systemd/journald.conf.d/99-persistent-journal.conf and restart systemd-journald.

Getting More Help

If these solutions don’t resolve your issue:

1. Check the FAQ for additional information
2. Contact support at support@exaviz.com

Last modified September 30, 2026