[BUG] BTT SKR Pico TH0 and THBed swap during operation

[csreades]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

During operation the thermistors readings for TH0 and TH Bed can swap. This results in the software reading the hotend as the bed temperature and the bed as the hotend temperature. THe overtemp/undertemp protections work as intended in these cases, calling Kill.

Bug Timeline

No response

Expected behavior

The thermistors to read their respective temperatures.

Actual behavior

The bed is read as the thermistor, the thermistor as the bed.

Steps to Reproduce

M155 S1
M140 S60

then wait until they swap

Version of Marlin Firmware

2.1.3

Printer model

No response

Electronics

SKR BTT Pico

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration_adv.zip

[csreades]

This is output of putty, the hotend thermistor was placed under a card onto of the heated bed so that it had a similar but not identical temperature. You can see where they swapped, which later caused the kill command.

[thinkyhead]

It's hard to say whether this is hardware or software without testing more RP2040 boards. I have an SKR Pico that I can try running with a monitor watching the temperature pins for anomalies, but there is no guarantee I could reproduce the issue.

I tend to think this is a hardware issue and not a software issue, because ADC reading is straightforward and also time-distributed. We first tell the ADC to start sampling a specific pin, and then after time has elapsed we get the value in the ADC. On the Pico we sample two ADC pins, 27 and 26. So the repeating order of operations is:

• Start ADC 27, Read Hotend Sample
• Start ADC 26, Read Bed Sample

In order for the values to get swapped, and not just overlap or be strange, there would have to be some issue where the steps get out of order. But the order is fixed and can never change at run-time. So then you would have to have this very specific order of success and failure to get swapped readings:

• Start ADC 27, Read Hotend Sample
• Start ADC 26, Read Bed Sample
• Start ADC 27, Read Hotend Sample
• Start ADC 26, Read Bed Sample
• Start ADC 27, Read Hotend Sample

But "read failure" can never occur, so we are only left with "started wrong pin," but this is order is fixed at compile time.

So the values being swapped is very strange.

For additional testing and data gathering, if you're not using the servo pin you could define a dummy TEMP_CHAMBER_PIN as pin 29 and define TEMP_SENSOR_CHAMBER as 1. Then you could see if the pins readings are getting shifted by one or randomly rearranged, rather than just being swapped.

[csreades]

When you say hardware issue do you mean on the RP2040, looking over this board schematic I cannot see how crosstalk so cleanly could occur? I am new to the Marlin codebase so I wouldn't know how the reads are handled. Is it possible that the switch and subsequent read is too fast in some instances and it grabs the historic reading from the ADC?

[thinkyhead]

I just don't know. It might be that the ADC "selected" state of all ADCs goes from "high" to "low" or maybe these pins are floating and one of them is turning into a capacitor. Without gathering more data it's a stab in the dark. I already stared hard at the code looking for some flaw that could exhibit a swapping as you demonstrate, and I just can't see how it is possible. The logic for ADC is hardcoded and the pin numbers are not stored in variables. The ADC gathering order Start 27, Get Hotend Result, Start 26, Get Bed Result is engraved in the code. Since nothing can happen at runtime to alter this machinery, we need to run an experiment with a third ADC sensor defined, to see what happens and see if it sheds any light on the cause.