Rock Pi 4B+ most GPIO pins flashing or dead

#1

I’m in the process of porting a VISCA/NDI camera controller from Raspberry Pi to run on Rock Pi (4B+ version 1.73), and I’m running into some serious GPIO hardware failures that I don’t quite know how to deal with.

As a starting point, I took a pre-built collection of LEDs and disconnected them from a working Raspberry Pi setup and connected them to the Rock Pi. They all worked fine when driving them from the Raspberry Pi, so I’m reasonably certain that the problems are specific to the hardware or drivers on the Rock Pi side, and are not bad LEDs or other wiring mistakes.

And I’m seeing the misbehavior from the mraa command-line tool, which likely rules out anything in my code. :slight_smile:

I’ve also tried switching to a different power supply, with no effect.

Here’s what I’m seeing when I do “sudo mraa-gpio set XX 1” for any given pin XX:

  1. Pin 32 (GPIO3_C0) works exactly as expected, and is the only fully functional pin.

  2. Pins 29, 31, 33, and 37 light up, but every 1.3 seconds or so, the brightness dips twice in short succession, in a rhythmic fashion. Apparently, these pins are 3V by default, and the working pin is 3.3V by default, so I’m thinking that the 3V regulator on this board is unstable for some reason, or that something is pulling the entire bus low, I’d like to set all the pins to use 3.3V, but I can’t find any documentation about how to do that.

  3. Pins 35, 36, 38, and 40 do not work at all. I’m guessing this is some secondary function interfering with it, but no overlays are turned on, and I can’t find any documentation that provides any other hints as to what might be wrong. I did notice that fdtfile was wrong (pointing at the 4c), and changed that, but it made no difference.

What’s even more bizarre is that pin 29 is turned on by default right after booting at about a 50% booting cycle (the Raspberry Pi does the same thing), and the LED doesn’t start the periodic flashing until I use mraa-gpio to change its state.

Any ideas? Another dud board? Kernel bug? Hardware bug?

Configuration:
Rock Pi 4B+
Armbian Jammy (Desktop)
MRAA library from top-of-tree on GitHub (because no Jammy binary builds exist for MRAA, apparently)
No overlays enabled
Tested with official Rock Pi power supply and Apple 87W USB-C supply

#2

Just to clarify, those nine pins are the only pins that I tested, because those are the pins that the existing wiring harness uses.

#3

I’ve determined that the flashing pins are dipping in brightness in sync with the obnoxiously bright blue heartbeat LED coming on. Unfortunately, the documentation for how to turn that off seems to be out of date (none of those paths still exist). Any idea how to turn that off in Armbian 22.04?

#4

Figured out the answer to the flashing problem. You can kill the blue status light with:

echo none > /sys/class/leds/status/trigger

typically added to /etc/rc.local. After doing that, the working GPIO outputs are stable. I still have no idea why all of GPIO4A is dead, though, unless there’s an incorrect pin mapping in MRAA.

#5

I’ve tried everything I can think of, all the way up to and including this:

cd /sys/class/gpio
echo 132 > export
cd gpio132
echo out > direction
echo 1 > value     # output high
echo 0 > value     # output low

for GPIO 132 - 137, which should cover the pins that aren’t working. Nothing happens. So I’m leaning towards dead board, unless somebody has any better theories.

#6

I decided to try a different kernel, and determined that:

  • 5.15.x kernels and later fail.
  • 5.10.x kernels and earlier work correctly.

Not sure the best way to report this, but I’d imagine that it is not specific to Armbian unless there are a bunch of missing patches, so consider this a bug report.

#7

Just for info: Some hardware problems I had with RockPi4 B have been solved by using a 12V power supply instead of 5V power supply.

#8

thank you for your report and sorry for late reply.
we’ll investigate this issue.

#9

and 12 are configured as I2S1 pins. it needs to be disabled by default.

#10

pin 19/21/23/24 have a problem too.

we fixed our “latest” kernel (currently v6.0) in BSP.

#12

I’ve used a gpt image for the inner emmc storage from your git repo (since everything else from the website is out of date for many years) https://github.com/radxa-build/rock-pi-4b-plus/releases but my board seems to have still the same problem described in this bug report. I’d like to use the GPIO pins which are currently reseved for I2S1 as outputs, but the system keeps them in their initial state if I change it (e.g. if I set pin 38 as output to low, it becomes high again right away).
Can you please describe how can I update the kernel you’ve mentioned?

#13

I’m not sure if you’re still having this issue, but we recently encountered this issue and have a resolution.
We are using rock-4se_ubuntu_focal_cli_b38.img from https://github.com/radxa-build/rock-4se/releases
It seems like the latest images from RADXA have i2s1 enabled by default, but with no way to disable it via rsetup. It appears that i2s1 is in use by default on the images.
One solution we found was to disable the snd_soc_rockchip_i2s module
Modify /etc/modprobe.d/blacklist.conf
Add “blacklist snd_soc_rockchip_i2s”
Reboot and those pins should now be free to configure via mraa or gpiod

image
image.jpg678×514 88.6 KB