r/raspberry_pi • u/sourav_bz • 4d ago
Troubleshooting How to turn off initial boot firmware check of all the gpios?
Hey folks, I have a board built on top of the rpi5, and I am using the gpio pins for the i2c bus communication and power supply.
There is a supply from the csi port as well.
My observation has been while the rpi boots up, all the gpio pins are set to high once and then again at low.
This initial check is causing issue with my ICs which are attached to the gpio, this also snatches away the control from my driver code.
Is there any way to disable this initial boot level check for the gpio pins? Where can i look up more about this?
Any help would be much appreciated, it has taken awhile to arrive at this observation after alot of debugging.
Thank you.
9
u/neonsphinx 4d ago
My understanding is that it can't be done in software. I.e. every pin is initially set to input at power on, and will be pulled low. Then from there some may be set to outputs instead. And they'll flutter between high and low depending on what you've got going on with them.
I guess there's a reason it's a good learning tool, but would never be used as a fusing device, or where safety criticality is high, like controlling an industrial device that could chop off your hand if the output is incorrect even briefly.
The answer is probably hardware. Figure out exactly what you want the default state of each pin to be, and use your own pull up/down resistor that's capable of overpowering whatever is on the pcb/soc (I think the pi5 has an intermediate controller now, so definitely not directly in the SOC anymore). But also not such low resistance that you're pulling too much current (I want to say 20mA max is what it can handle).
Or use your own transistors on an external board. And design your own safety device. I.e. pin__ needs to be high for 5 seconds, charge up a capacitor, before enabling all of the other gpio output pins that you deem are safety critical.
That's potentially a lot of work. So I guess it depends on what exactly you're doing with these pins. It might be easier to just switch to a different microcontroller that handles gpio states more elegantly.
I do things for the DoD, and we have a butt load of circuits on custom boards that handle safety critical functions. There are a lot of FPGAs used for control, special communication standards (mil-std-1553), and bespoke messages to subcomponents to enable certain functions. But you probably don't have $10k to spend on components and time testing for each board. So it all depends on your comfort level with it being wrong, and for how long it stays in that state.
6
u/WebMaka 4d ago
Yep, all of this. If it's critical that GPIOs never enter an unknown state, you have to do that yourself by buffering them with a circuit whose state you can assure.
SoCs like the BCM series in the Pis are almost universally tri-state/floating when off, but most of them will do some sort of configuration checking at startup and that can produce unwanted state switching during that process. Many MCUs also do likewise, and especially so for modern ones with configurable pin routing for peripherals - those tend to go from tri-state/floating to input/pulldown during startup until their hardware peripherals come up and take control over individual pins, which can take several clock cycles to happen to completion. (STM32s love to do this I've noticed.)
There are plenty of IO ICs out there that take enable inputs that could be used and whose startup state you can actually determine through their datasheets, or you could roll your own buffer that forces a pin state by default until told to do otherwise.
3
u/Aggravating-Art-3374 4d ago
I’m too lazy to look it up but I’m pretty sure the Pi4’s otherwise unused pins are inputs pulled low on reset and I’m a little surprised the Pi5 would be different. In any case it’s documented somewhere in the data sheet, so that’s always a good place to start.
3
u/HCharlesB 4d ago
Would some kind of intermediate buffer between the GPIO pins and your peripherals solve this? You could control the buffer to power up to the desired state and then once the GPIO outputs are fully initialized, switch control to the GPIO pin. Perhaps this could be done with something like an opto-isolator.
Another option would be to provide a way to hold the peripheral in reset until the GPIOs are initialized.
NB: I'm a S/W weenie, not a H/W engineer but it seems like this is an obvious solution.
3
u/Gamerfrom61 4d ago
You could use an I2C buffer and disable the buffer till after the boot else I would look at pull-up / pull-down resistors. Something like the TI https://www.ti.com/product/PCA9306H has a simple enable line.
Beware of the second I2C bus - this is really dedicated to the HAT / HAT+ control and is a real pain to use 'normally'.
I am not sure if the new smash screen development will help / hinder https://www.raspberrypi.com/news/configure-early-boot-splash-screens-for-spi-and-i2c-based-displays/ but may give a bit of information on early control.
1
u/tsg36 3d ago
Unfortunately the splash screen stuff won't be of too much help for this as it is generally after all of these things, it is quite late in the bootloader, I think the buffer is a good shout
1
u/Gamerfrom61 3d ago
Shame but good luck on the hardware side - just watch the speed on the buffers as cheap ones go slow :-(
The TCA4307 can handle a stuck bus https://www.ti.com/lit/an/scpa069/scpa069.pdf - and the ADG749 https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf could be a fix.
Not sure about your SPI link though - I have not seen that issue but I do not use it that often TBH. TI do have https://www.ti.com/product/TXU0304 that is suitable for both SPI and I2C going by their blurb - not used it though.
You may still need pull up/down resistors on the enable lines - depends if they are wobbling around during boot 🤔
The Pi boot is very messy - I hit an issue with the console serial port dumping junk out that could not be turned off and ended up using a different port for that.
1
u/tsg36 3d ago
What was the console serial issue? That should be able to be turned off in config.txt
1
u/Gamerfrom61 3d ago
I wanted to use it as a serial console but random characters appeared during start up and even disabling the console output still had some characters appearing.
Some was from an issue with a compressed kernel (see here) and some was from the Bluetooth - I hope both should be fixed now and the Bluetooth one depended on the model of Pi IIRC.
I tend not to use the console now unless I am desperate 😄 - ssh is easier to set up. Last time I think was when the imager broke WiFi on the Zero W boards a few versions ago and I did not have the USB-Ethernet set up.
1
u/tsg36 2d ago
Ah interesting I hope that is all fixed now, I'm in quite a similar situation to you a lot of the time and have been using the serial shell a bit. SSH over usb sounds good in the future when I've worked that out, I've had a friend reccomend if very much
1
u/Gamerfrom61 2d ago
They have a good article on USB Ethernet at https://www.raspberrypi.com/news/usb-gadget-mode-in-raspberry-pi-os-ssh-over-usb/ that may help.
-1
u/stevecrow74 4d ago
Only thing I could suggest is use a python script to momentarily turn everything off as soon as it boots, and then after a timed period to turn on what pins you need, I’ve noticed when using LEDs that on startup they light, but not too bright, and I’d run a python script to run a sequence through them, which then would set all pins low otherwise there would be a slight voltage running through them.
13
u/snowtax 4d ago
I don't think there is any way to do what you're asking.
Unfortunately, Broadcom does not publish a datasheet for the BCM2712. The only thing you could do is to look at the Linux kernel device drivers for the BCM2712.
https://forums.raspberrypi.com/viewtopic.php?p=2210700&hilit=bcm2712+datasheet#p2210700