Pi 4 locks up with a kernel oops as soon as both spi4 and spi5 overlays are on
Not my usual area, I’m an IT guy who got handed the energy team’s sensor Pi.
Pi 4B 4 GB, Raspberry Pi OS Bookworm 64-bit, kernel 6.6. Two Adafruit MAX31865 boards with PT100s on the boiler supply and return lines. Whoever built it put each board on its own SPI bus:
dtoverlay=spi4-1cs
dtoverlay=spi5-1cs
Either overlay alone works. Both together: the first read of the second bus gives
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
...
pc : bcm2835_spi_transfer_one+0x...
Kernel panic - not syncing: Oops: Fatal exception
and the box is gone until power cycle. The readings go to Hermetry, so of course the device just goes offline and we get the offline alarm at 3 am. Is spi4 + spi5 at the same time a known problem? I’d rather not have to understand the kernel source.
Is anything else enabled in config.txt? enable_uart, other overlays? Paste the whole file.
enable_uart=1 (serial console is on, someone uses it for headless recovery), dtparam=i2c_arm=on, and the two SPI lines.
I ran into nearly the same thing on a lab Pi 4 with two thermocouple boards. I never got to the bottom of the kernel side, so I can’t tell you whether it’s a driver bug. But spi5 sits on GPIO12 to 15, and GPIO14/15 are also the UART pins your console is using, so with enable_uart=1 two overlays are fighting over the same pins. That alone is enough for me not to trust the setup.
What I did, and I’d do it again: you don’t need two buses for two MAX31865s. They are SPI devices with their own chip select, so both sit on SPI0 with CE0 and CE1:
# /boot/firmware/config.txt
dtparam=spi=on
# remove the spi4-1cs and spi5-1cs lines
Wiring: SCLK GPIO11, MOSI GPIO10, MISO GPIO9 shared by both boards. CS of board 1 to CE0 (GPIO8), board 2 to CE1 (GPIO7). In CircuitPython / Blinka that’s digitalio.DigitalInOut(board.CE0) and board.CE1 as the CS pins. The MAX31865 is happy at 1 MHz, the shared bus is nowhere near busy reading two temperatures every few seconds.
Keep the PT100 config (2/3/4 wire) the same as it was per board, otherwise your readings shift by a few degrees and someone will open a ticket about the boiler.
Separate question, can you get an alarm when only one of the two temperature keys stops arriving? We had a board die quietly and the device stayed online.
Moved both boards to SPI0 with CE0/CE1, removed the two overlays, three days without a crash and the readings match the old ones within 0.1 °C. Thanks Aoife. @Keisha the offline alarm wouldn’t help there since the Pi is still online. A threshold rule can’t see a missing key either, as far as I know. We’re looking at a flow watchdog for that.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.

