I just purchased a Beaglebone Green Wireless and a Beaglebone Relay Cape. The BBGW was flashed with the latest debian and properly boots. When I connect the relay cape, all lights are light up solid. I cannot connect to the BBGW.
The Relay cape works fine on my Beaglebone Black though.
I don’t have BBGW board, so all of this is just a GUESS.
My thoughts are you have to find the correct overlay. You are dealing with legacy stuff and who knows what image you have. You will have to post the image versions on here so the help can be refined. What code are you using to access it?? Plenty of variables and many changes to deal with.
In /boot/uEnv.txt, there are some particulars to add/subtract.
If you only need micro SD Card, uncomment eMMC.
If you only need the Relay Cape and no HDMI, uncomment the HDMI line too.
For the Relay Cape, check in /boot/overlays/ and see if the .dtbo is located in those files. I am going on pure memory, i.e. so I may be off on the location of the .dtbo file(s) for the Capes.
Seth
P.S. Once you reboot without the Cape attached, see if it boots. I am not sure why the Cape interferes with the booting process like you stated. Also:
What does the output of these commands state:
uname -a
cat /etc/dogtag
I have a board around here somewhere. I need to find it and try to see what image I have on it and if the Relay Cape works still with it.
Where beagleboard.org files the listed .dts or .dtsi for the BBGW may help answer some questions.
Also, look at their BeagleBoard-DeviceTrees on github or on openbeagle.org.
The Device Trees source files will help out greatly…
I was more into these boards but it has been a while. I think there was also some type of resistor somewhere on the board that controlled specifics but I have less of a memory on it right now.
Seth
P.S. Those notions above should get you to understanding the listed pin(s) availability and what is taken up and where…
That may work too. I remember now. On some of the 5.10.x kernels, there was a bug I could not find but it had to do with reset and power. I would blame a bug on the am335x but I do not know enough about it.
If I check the past boot logs with journalctl --list-boots, none appears for booting with the relay cape. I only see boot logs for when the relay cape is not connected.
so in uEnv.txt, the bootcmd line has “quite” at the end, remove this, then you will see the full boot output from the serial interface. if you host is linux, use “sudo minicom -C boot.log” and once the device is finished booting. close minicom and your boot.log file we have everything. if your on windows, your on your own in how to capture the boot log.
Are you sure the physical cape is not damaged in some way that is shorting something on the headers. I am not aware of any way that cape could interfere with boot. Its essentially a passive device when on the bus.
When you have the problem do you mean with overlay installed or cape physically installed on the board?
i2c is used to distinguish this Cape from others on Pins 19 and 20 of P9.
if you look at the schematic for the Relay Cape, try to use just the GPIO pins used on the BBGW for accessing the On/Off mechanisms in the Relay Cape without attaching it.
So, do not apply the i2c pins to the Cape and try to just use wires, e.g. Male to Female for your respective use case in the Relay.
Also, send in where you got your image. This may help me understand what to do…
Seth
P.S. Then, if all else fails, try to look at the i2c in use for detecting the Cape in the device tree source file(s). You may have to switch a 1 to 0 or a 0 to 1, i.e. depending on your source for the i2c pin in use.
Also, /dev/bone/i2c/ may be where your files are found for porting to the Relay Cape.
You may need GND and a power source from your BBGW too. I have NOT tested this idea out. If you are willing to try it, okay. If not, you can wait for others to keep helping or I can test one day.
Debian image for BeagleBone Black on-board eMMC flash Kernel: 5.10.168-ti-r71 U-Boot: v2022.04 default username:password is [debian:temppwd] For flashing instructions or other images, see https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshot-2023-09-02/31280
Your intuition about wrong pin mapping makes sense. However for the sake of time, I may simply revert to using BBB. Would have liked wireless. Might get back to BBGW if someone finds a solution or when I have more time to investigate.
If you’re still struggling to get the relay cape working on that legacy board, my honest advice: toss it and move on to something current and actively supported. If you can’t get basic functionality working in a reasonable amount of time, it’s just not worth the effort. Your time and sanity are far more valuable than a $100 board.
Unfortunately, much of the embedded hardware ecosystem seems intentionally fragmented—plagued by unclear documentation, rapid obsolescence, and just enough support to keep you chasing your tail. This isn’t a bug; it’s part of the revenue model. Don’t fall into the trap of throwing good hours after bad. Use hardware that respects your time.