Communication exception
Hi pikelcw ,
Sorry about not circling back. Have been underwater overall. I could not figure out how/why this is happening. It seems to actually have something to do with the CM4 modules themselves, as far as I can tell. And specifically, if they are eMMC or uSD.
We can send you one of these to address it for sure if that works for you:
If so please shoot an email to support@luxonis.com and we'll get one sent your way.
Thanks,
Brandon
Shoot. So odd. We could try sending you another one? I'm not sure what makes some refuse to boot w/out HDMI and others don't have a problem.
@pikelcw I tried to use the CM4 without HDMI and couldn't boot it up too, same after sudo rpi-update
. Also hdmi_safe
or hdmi_force_hotplug
flags didn't work, tried disabling desktop GL driver, setting default desktop resolution (both via raspi-config
or manually editing /boot/config.txt
) or even disabling HDMI completely and setting the default to composite output.
I'll investigate with the team further and circle back with more details. Seems that the OS is not booting at all without HDMI, but here is the /boot/config.txt
I used if needed for reference
- Edited
As another update it is seeming that this does depend on the CM4 module itself. With a given module we could not get HDMI boot on one module, and it would boot on the other - and this followed the CM4 module itself - no matter what Luxonis board we put it on. Even across different revisions of the Luxonis carrier board.
Test we did below:
Two OAK-D-CM4 (DM1097_R0M0E0), both equipped with the same CM4-Lite WiFi capable Raspberry CM4 modules.
I have tested both with the same uSD card one after another:
- first OAK-D-CM4 1 with CM4 Lite module 1 I was able to boot it without the HDMI attached, and the LED works as on the CM3 in your case.
- second OAK-D-CM4 2 with CM4 module 2 won't boot and the ACT LED does not blink at all as you observed (tested with the same uSD)
- after this test I swapped the CM4 modules on both devices and now the first device 1 with CM4 module 2 won't boot and the device 2 with CM4 module 1 will
So it has to be related to CM4 module, not sure but might be related to CM4 bootloader as there probably are some deviations across the different CM4 modules.
We're wondering if some of the modules simply need a bootloader update. We're investigating in this direction:
https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md
- Edited
We looked into this issue thoroughly today and we found out that it is actually not related directly to the HDMI connected or not, as we first thought that if it is not a bootloader it must be something with HDMI interface signaling/detection.
But the issue really lies somewhere else, that is in the power up procedure. We found out that Raspberry Pi CM4 datasheets states that
All pins should not have any power applied to them before the +5V rail is applied.
We come to that when seeing that device boots up successfully w/out HDMI connected, if the PSU is immediately reattached to the barrel jack connector after disconnection (in ms), or sometimes when PSU is first connected to the jack and after that to wall plug.
To get to the point; we are using external power supply for 3V3 rail which is connected to the RPi CM4 module over pull-up resistors on the input/output signals going to/from the CM4 module.
After 5V is applied, it seems that the 3V3 rail rises to quick (1ms) and kind of a latch-up happens.
We modified the hardware enabling the PMIC with 3V3 generated from RPi, that way ensuring 3V3 power rail voltage will always rise later than 5V is supplied. That resulted in all boards boot up without HDMI connected, no matter the version,, CM4 module variant used... It boots, if we are using CM4 Lite with uSD and booting from there, or if we attach the CM4 with eMMC, booting from eMMC.
Modification that works for now: removed the 10k PU from EN pin on PMIC, and connected EN pin to CM4_3V3 rail.
We believe that the reason for that some of the CM4 modules booted - no matter what Luxonis board we used it on (Luxonis carrier board) while some didn't, is that we were/are really on the edge here with this issue.
On the other hand and we are not aware of the exact boot procedure on the CM4 and what causes the latch before boot, so can not explain the real reason behind this.
Nevertheless in the Raspberry PI compute module datasheet is clearly stated that none of the pins, on a CM4 module, should have any power applied to them before the +5V rail is applied. We are also not sure about why connecting the HDMI cable solves this issue, it could be that the CM4 has different boot procedure when HDMI is connected or not.
To close that up, we will update the design and we can also offer sending a reworked unit for now for everyone affected by this issue.
We are sorry for any inconvenience brought in by this issue.
Best regards David,
Luxonis lead EE
Brandon
Sorry for the late reply. Here's the link https://www.dfrobot.com/product-2196.html.
David
Thank you for the update. How can I get a reworked unit?
Sorry about the trouble here.
Could you please shoot us an email at support@luxonis.com and we'll get a new unit shipped to you ASAP.
Thanks,
Brandon
(We'll rework a unit and send it to you... future production will have this design fix.)