Unstable temperature readings on Marlin 2.1.2.7 with MKS Robin Nano v1.2 + MKS TFT35 (LVGL UI)

[JucaTec]

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

Yes, and the problem still exists.

Bug Description

Hello everyone,
I’m facing a persistent issue with unstable temperature readings when using Marlin 2.1.2.7 on the following hardware:
Board: MKS Robin Nano v1.2 (STM32F1)
Display: MKS TFT35 with LVGL UI
Thermistors: EPCOS 100K (verified with multimeter)
Pull-up resistor: 4.7kΩ (confirmed on board)
Hotend and Bed: both affected
Problem
Even at room temperature (idle, no heating), the reported temperature values are unstable and jump constantly, for example:
22 °C → 25 °C → 27 °C → 23 °C → 26 °C
This happens on both hotend and heated bed.
Because the temperature reading itself is unstable, PID tuning does not solve the issue. During printing, especially when the part cooling fan turns on, the hotend temperature drops and the controller struggles to compensate properly.
This strongly suggests that the problem is not PID-related, but rather ADC reading / temperature measurement instability.
What has been tested
Verified thermistors and pull-up resistors with multimeter
Confirmed hardware works correctly with original MKS firmware
Tried:
Different PID values
Default Marlin PID values
PID autotune
Oversampling adjustments
Slower temperature read intervals
Issue only appears on Marlin, not on the original firmware
Observations
The instability occurs even without heating
Values jump in whole degrees, not smooth noise
Happens on STM32F1 + MKS Robin Nano
Using LVGL UI (MKS TFT35)
This makes me suspect a problem related to:
ADC sampling / multiplexing on STM32
Interaction between LVGL UI load and temperature ISR
Or a regression/change in Marlin temperature handling for STM32 boards
Request for help
Has anyone experienced similar behavior on MKS Robin Nano (STM32F1) with Marlin 2.1.x?
Any guidance on:
Known issues with ADC sampling on STM32F1
Recommended fixes or patches
Best practices when using LVGL UI with Marlin on this board
would be greatly appreciated.
Thank you for your time and support.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

2.1.2.7

Printer model

Two Trees Shapphire Pro SP-3

Electronics

MKS Robin Nano V1.2

LCD/Controller

TFT35

Other add-ons

MKS UI LGVL

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

No response

[thinkyhead]

Would you be able to test some bugfix-2.1.x commits to narrow down the cause?

The strategy is to find a commit from some point in the "distant" past where the feature works. Then, test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact day where it broke.

If you started from a point 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

The tool we use to do this is git bisect and it is more direct and effective than other potential approaches.

To get assistance with this process get in touch with us on the Marlin Discord.

[JucaTec]

Thanks for the suggestion.
I didn’t know exactly which version was “good”, but I’ll start a git bisect
from an older point in bugfix-2.1.x and try to identify the regression commit.

[JucaTec]

Hello. Problem solved. It's not a Marlin bug.

The MKS Robin Nano v1.2 board uses 3.3V directly from the power supply on the microcontroller's reference pins, but the ripple on the reference pins was greater than on other points of the board.

Near the reference pins there is a 100nF ceramic capacitor. I added a 470nF SMD ceramic capacitor and a 1uF tantalum capacitor. The ripple became almost the same as the rest of the board and the temperature measurement oscillation stabilized.

Thank you and I hope this helps other people.