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-1csEither 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 exceptionand 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 linesWiring: 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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.