New: the AI firewall watches the whole platform and explains each incident in plain words. See how it works

Pi 4 locks up with a kernel oops as soon as both spi4 and spi5 overlays are on

Pi 4 locks up with a kernel oops as soon as both spi4 and spi5 overlays are on

Solved 5 4

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.

♥ 1

Is anything else enabled in config.txt? enable_uart, other overlays? Paste the whole file.

Timestamps in UTC or it didn't happen.
♥ 0

enable_uart=1 (serial console is on, someone uses it for headless recovery), dtparam=i2c_arm=on, and the two SPI lines.

♥ 0

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.

Timestamps in UTC or it didn't happen.
Accepted solution♥ 2

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.

♥ 0

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.

♥ 0
Viewing 6 posts – 1 through 6 (of 6 total)
  • 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.

Share