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.
/boot/dtbs/5.10.168-ti-r79/overlays are where the files are located.
Also:
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
I have disabled these to make the Cape work as I do not need eMMC, Video, and/or Audio.
Try to disable those first and see how far you get. Then, report back if there is something else not working.
Seth
> uname -a
Linux BeagleBone 5.10.168-ti-r68 #1bullseye SMP PREEMPT Mon Jul 31 21:58:32 UTC 2023 armv7l GNU/Linux
> cat /etc/dogtag
BeagleBoard.org Debian Bullseye IoT Image 2023-08-05
The .dtbo file BBORG_RELAY-00A2.dtbo is there for the relay cape, along with others:
> ls /boot/dtbs/5.10.168-ti-r68/overlays/
AM335X-PRU-UIO-00A0.dtbo BB-NHDMI-TDA998x-00A0.dtbo
AM57XX-PRU-UIO-00A0.dtbo BB-SPIDEV0-00A0.dtbo
BB-ADC-00A0.dtbo BB-SPIDEV1-00A0.dtbo
BB-BBBW-WL1835-00A0.dtbo BB-UART1-00A0.dtbo
BB-BBGG-WL1835-00A0.dtbo BB-UART2-00A0.dtbo
BB-BBGW-WL1835-00A0.dtbo BB-UART4-00A0.dtbo
BB-BONE-4D4C-01-00A1.dtbo BB-W1-P9.12-00A0.dtbo
BB-BONE-4D5R-01-00A1.dtbo BBORG_COMMS-00A2.dtbo
BB-BONE-LCD4-01-00A1.dtbo BBORG_FAN-A000.dtbo
BB-BONE-NH7C-01-A0.dtbo BBORG_RELAY-00A2.dtbo
BB-BONE-eMMC1-01-00A0.dtbo BONE-ADC.dtbo
BB-CAPE-DISP-CT4-00A0.dtbo LED_P8_03.dtbo
BB-HDMI-TDA998x-00A0.dtbo LED_P8_04.dtbo
BB-I2C1-MCP7940X-00A0.dtbo M-BB-BBG-00A0.dtbo
BB-I2C1-RTC-DS3231.dtbo M-BB-BBGG-00A0.dtbo
BB-I2C1-RTC-PCF8563.dtbo PB-HACKADAY-2021.dtbo
BB-I2C2-BME680.dtbo PB-MIKROBUS-0.dtbo
BB-I2C2-MPU6050.dtbo PB-MIKROBUS-1.dtbo
BB-LCD-ADAFRUIT-24-SPI1-00A0.dtbo
I disabled most overlays, and still have the same issue. Will not boot with the cape connected. Solid blue lights.
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
disable_uboot_overlay_adc=1
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
Probably something with the eMMC onboard the BBGW.
It could be taking some extra pins…
I could check again but I am sure you can check if need be now. So, look at https://files.seeedstudio.com/products/102010048/BeagleBone_Green%20Wireless_V1.0_SCH_20160314.pdf at their BBGW and maybe look at:
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…
Oh and just hit the reset button…
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.
Seth
Ok, I installed an SD card and made it bootable. No longer using eMMC. The OS has this latest version:
debian@BeagleBone:~$ cat /etc/dogtag
BeagleBoard.org Debian Bullseye IoT Image 2023-10-07
debian@BeagleBone:~$ uname -a
Linux BeagleBone 5.10.168-ti-r72 #1bullseye SMP PREEMPT Sat Sep 30 03:37:21 UTC 2023 armv7l GNU/Linux
I modified the /boot/uEnv.txt as such:
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
When I add the relay cape, still get the same problem - 4 solid blue lights. Reset does not change the behavior.
can you post your boot log?
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.
/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.
Also…
This section seems to be a bit outdated: https://forum.beagleboard.org/tag/latest-images
Try the website at beagleboard.org and search for images.
The distro (beagleboard.org/distros) when filtering for BBGW gives BBB:
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
I installed the latest:
am335x-debian-11.8-iot-armhf-2023-10-07-4gb.img.xz
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.
I have 2 BBGW and 2 capes. Any combination results in the same behavior.
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.