Several analog-domain causes that aren't visible in the code. The most common is insufficient sampling time for the source impedance: the ADC charges an internal sample-and-hold capacitor through the source, and if the source impedance is high and the configured acquisition time is too short, the cap doesn't fully settle and you read a value skewed toward the previous channel's voltage (charge sharing), the fix is a longer sampling time or a buffer/op-amp to lower the source impedance. Other causes: a noisy or inaccurate Vref scaling all readings; exceeding the input range (above Vref reads as full-scale and may damage the pin); missing or inadequate anti-alias filtering letting noise fold in; ground bounce or sharing the analog ground with noisy digital returns; and not averaging, so single-sample noise dominates. So "the code is correct" but the analog front end, impedance, settling, reference, grounding, filtering, is where ADC bugs usually live. The debugging approach is to check the analog conditions (source impedance, sampling time, Vref quality, grounding) rather than the register sequence.
Embedded Systems Fundamentals · Interview question
Why might an ADC reading be wrong even though the code looks correct?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
ADC & DAC
Bridging the analog and digital worlds: how an ADC quantizes a voltage to an N-bit count (and a DAC reverses it), the count↔voltage math, and why Vref and Nyquist set your limits.