So I just got my uConsole and I’m struggling to get it to boot properly. I’m using a CM4 with EMMC which I flashed using a different carrier board via USB. This worked great for a few hours and a few reboots until I tried to power up this morning. Right after boot, the speakers let out a short low beep and the screen froze with a lot tearing and glitching. When this fault occurred, it was on battery and usb c power. I shut it down again and tried to reboot but the screen only flashed for a second and then nothing. I’ve tried reimaging the pi, reseating every connector and booting without battery. Every time I try, I just get a brief screen flash. Any ideas? Right now I’m thinking it may be a hardware failure, but I’m going to try to redownload the image in case it was corrupted somehow. Thanks!
Just to add, I tried redownloading the image as well as the lite/xfce version and still just getting a screen flash and no boot. I’m starting to think either my pi or the uconsole main board is dead.
You do know that this forum warns you if your topic is related to one posted earlier? You’re not helping this forum by making your question stand out. This isn’t Reddit.
Anyway, based on the details you provided, I’m starting to think your main board is at fault. Why will the CM4 allow you to flash an image to its eMMC if it is compromised?
There should be a green LED next to the power button. If it doesn’t stay on, it’s gotta be a problem with the main board. Check for loose or missing parts. E-mail help@clockworkpi.com right away.
Sorry about the topic, my intention wasn’t to click bait. When posting, I didn’t see any topic that related to others. Lots of “unable to boot” but no “booted fine a few times then stopped working”. I’ll be sure to be mindful of this in the future.
I won’t pretend to understand the USB EMMC flashing mechanism on the CM4. However I anticipate it could be possible that the firmware responsible for this may be functional while something else is compromised that prevents the pi from completely booting.
I have attempted to boot on a carrier board with standard pi images with no luck. I did only try this briefly so I’ll have to look further into it.
The power led stays on without issue. I’ve reached out to the help email and am awaiting response.
Any idea what the process is if the main board is at fault?
This is a game changer. Perhaps there’s something wrong with the eMMC. You’ve also mentioned your uConsole was fine for a couple runs before the incident. How old is your CM4? Has it been used for disk I/O intensive workloads? You may need to plug in your uConsole to an external monitor to see what’s wrong. It would also be great if you have a spare CM4 to test if the mainboard really is at fault.
OK, now that sounds like a problem with the CM4.
The CM4 I was using was used for a few other projects and had a good amount of read and write cycles on the emmc. I ordered a CM4 lite and sd card to test with.
After some discussion with support, they suspect it’s the main board. They’re sending me a replacement so later this week I should have a better idea of what went wrong.
Turns out the CM4 died. Got a replacement CM4 lite today and it booted no problem with an SD card. Thanks for the help!
And now I know why a CM4 with built-in storage can become a disaster. Thanks for the tip.
Reviving this conversation because I’m having a similar issue… Today, I assembled a new uConsole with a CM5-108000 (RK3588S) compute module. On the very first power-on, the system booted immediately from the microSD card and appeared to operate normally. I then performed a clean shutdown. When I attempted to restart the device, however, it failed to boot. The power LED glows steady green and the SoC becomes moderately warm, which indicates that it is drawing power and showing some partial activity. The LCD remains completely dark, with no backlight at any point, and the system does not respond to a USB keyboard test. Even after waiting more than a minute, the Caps Lock LED never toggles.
To troubleshoot, I first confirmed that power is not the issue. The battery is around fifty percent charged and I also tested with a reliable 5V/3A USB-C supply. I forced a complete shutdown by holding the power button for twenty seconds, disconnected power, and then reconnected everything, but this made no difference. I then turned to the microSD card. I replaced the original card with a brand-new Samsung card, reflashed it with a fresh copy of the stock image, and tested again. The problem persisted.
I next checked connections. I reseated the LCD ribbon cable several times, making sure it was firmly locked, and I also removed the CM5 module, inspected the contacts for damage or debris, and reseated it carefully. Nothing changed. I tried booting both with the LCD connected and disconnected, but in either case the system behavior was identical. With no mini-HDMI cable available I have not yet been able to test external video, but attaching a USB keyboard produces no activity, suggesting the device is not reaching an operating system.
The SoC does warm up slightly, though not as much as it did when Linux was actually running, which suggests it is powering but hanging before it can initialize the display or load the operating system. Because the CM5 does not rely on an external EEPROM, this seems to indicate that the boot ROM inside the SoC is failing to load properly from the microSD.
I am interested to know if others have seen a similar failure mode with the CM5, where the unit boots successfully once and then will not boot again. Could this be explained by a fault in the carrier board’s SD interface, or does it point more likely to an early failure in the CM5 module itself? Also, should the CM5 at least power the LCD backlight even without a valid operating system present? I’m feeling stuck on this one…
First are you using a RPi CM5-2712 or a Radxa CM5-RK3588S big difference on what it could be. If it’s the RPi CM5 then when you had it booted the first time you needed to edit the EEPROM to the settings outlined here. It’s the first thing you should do next time you get it booted.
To try and get it working again, remove the batteries it makes shutting down a failed boot easier. You cannot shut the device down by the power button on a failed boot. You need to just pull power. Try smaller SD cards and a few different ones. Once you apply the EEPROM settings change then any SD card will work.
I started with a stock CM4 running Bookwork and it was very stable. I replaced with CM5 and latest Bookworm (as of 2 weeks ago) and even with the recommended config fixes, it was ultra unstable. Even with low temps, it would boot but within a minute or two, just hard crash / power off.
I then tried it all with Trixie and it is much more stable - as long as I don’t push it very hard. 34C idle and it’s fine. 40-45C doing moderate things, its probably stable for hours but may hard crash in a day. If I use Handbrake to convert a video and temps go up to 45-50C, it will probably hard crash.
When replacing the CM5 I followed another thread here’s advice and have a thermal pad and heat sink. But that said, shouldn’t the CM5 just throttle down and not just crash constantly when any kind of non trivial use is going on?
are you on battery or mains power when this happens? i can push the cm5 hard and get it upto 62c with a m.2 heatsink on the back but it won’t crash or power off as long as my battery isn’t low. it won’t even thermal throttle.
After battling this all night long, with at least 5 complete tear down and rebuilds, the CM5 snapped into the carrier board a bit more snugly. Et voila. It works. What amazing side adventures I took to fix a bad connection.
The misadventure, illustrated: xkcd: Repairs
Mains most all the time, though the hard crashes don’t seem to correlate to main or battery. It happens on both.