Raspberry PI 5 thermocouple fails

General Discussion
1

Basic Information:

Printer Model: Ulti Steel
MCU / Printerboard: SKR 2 STM32F429
Host / SBC Raspberry PI
klippy.log
klippy (7).log (97.8 KB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

After upgrading from raspberry pi 3B to 5 I always got thermocouple fault and seeing -249 degress, I checked SPI with analyzer, there is no data packets besides only couple 0x0 and 0x1.
Then I tried to power BTT MAX31865 from 5V from rgb pin and it worked, because it could successfully initialize before SPI communication.

Now I have on table setup of skr2 + btt 31865 + pt100. When I switch SD card to raspberry pi 3 it works, when I switch to raspberry pi 5 - it fails. I guess the problem that it is much faster and delay between startup and probes becomes too low.

2

This seems very strange. According to your config, the MAX board is connected to the MCU. Is this understanding correct?

As such, the SPI code of the MCU should be responsible for addressing the MAX board and be unrelated to the host’s CPU.

1 Like
3

Correct, it’s driver-like board of 2nd version BIGTREETECH-MAX31865/BIGTREETECH MAX31865 V2.0 at master · bigtreetech/BIGTREETECH-MAX31865 · GitHub

I know that’s strange, but on the other hand, SPI code is being controlled by spi_temperature.py which runs on pi

4

Also, I’ve tried switching skr boards, 3186 “drivers” and that didn’t help. Boards were tested using PSU, on the table, without any drivers or wires, only 3186 connected and PT100 into driver socket and shielded blue usb from raspberry.

5

JFYI:
spi_speed: 400000 is a little strange, the default is 4000000
Software SPI does not support rate limit, but it is probably running slightly slower than 4Mhz.
MAX31865 by itself supports up to 5Mhz, according to the datasheet.

6

Also, there is a error with initializing of TMC drivers,
and looks like your MAX31865 configuration is missing the CS pin.
My bad, looks like for this sensor the name sensor_pin: PD12 is used.

Thermocouple is handled on the MCU side, so I don’t think it can be releated to the SBC in any way.

Receive: 94 1309.738376 1309.737922 11: seq: 19, clock clock=1093385517
Receive: 95 1310.410354 1310.209454 14: seq: 14, thermocouple_result oid=18 next_clock=1256640000 value=0 fault=0
Receive: 96 1310.710364 1310.427693 14: seq: 18, thermocouple_result oid=18 next_clock=1307040000 value=0 fault=0
Receive: 97 1310.722524 1310.722410 11: seq: 19, clock clock=1258718820
Receive: 98 1311.010388 1310.722410 14: seq: 19, thermocouple_result oid=18 next_clock=1357440000 value=0 fault=0
Receive: 99 1311.010391 1310.722410 12: seq: 19, shutdown clock=1307043909 static_string_id=Thermocouple reader fault

FWIW, there is no code to reset the sensor, only to initialize it.
So, technically, even if there is a some sort of race condition, where sensor is not ready and klipper tries to initialize it.
You can simply restart klipper, like FIRMWARE_RESTART after the first unsuccessful initialization, and the second one should be successful.

7

Yeah drivers were disconnected during tests as I mentioned above.
The interesting thing is that on rpi 5 I always get the error and by manipulating REPORT_TIME and MAX_INVALID_COUNT - setting them to high values and restarting klipper service I could finally get correct readings. Though this works only for some period, then mcu fails again.

8

This sounds and looks like a sort of hardware issue to my taste.
If you have appropriate equipment, I suggest you look at SPI signaling.
I’m not sure that I can assist you here without that sensor.
Only make general recommendations; it should work without 5v, and power from the motor driver mount should be enough.
Probably, there will be 3.3v on both sides.

About hypothesis that RPI5 is too fast, you can easily validate that, be simply clocking down RPI5.

/boot/firmware/config.txt:[pi5]
/boot/firmware/config.txt:arm_freq=1000
/boot/firmware/config.txt:arm_freq_min=1000

Or even lower, if you wish to.

Maybe there is just a supply power difference between RPI3 and RPI5, what causes strange issues. IDK, generally there is a SBC to MCU connection error, not the error with SPI located on MCU.

Just in case anyone is curious, there are schematics.

image
image2000×1413 206 KB

image
image1920×702 197 KB

So, with jumpers on SKR, SPI is directly connected to the MCU.