What can be giving incorrect ADC readings when transferring code from Nucleo to PCBA?

[ron_w]

I've been working on some code to control a 4-wire touchscreen on DisplayTech's DT028BTFT-TS using timers to de-bounce the respective touch screen wires.

The code works on the Nucleo-F413ZH under debug and standalone. The coordinates of the positioned touched are calculated using the microcontroller's ADC with the coordinates being displayed on the LCD. 

However, when using the code on the PCBA on which it will be used it gives 4095 for both the x and y coordinates of any touched position. I've gone through with a debug (the ST-LINK/V2 in-circuit debugger) and can see the value has been returned by 'HAL_ADC_GetValue(...)' as 4095.

I've:

- checked the tracking on the PCBA and am happy with that;

- increased the timeout for 'HAL_ADC_PollForConversion(...)' from 10 to 100 but still get 4095 for both coordinates.

Does anyone have any suggestions what might be the cause or what I can look at, please? I did have a further issue with HAL_Delay but solved that by setting the all the NVIC 'Preemptive Priorities' to '1' except for the 'Time base: System tick timer' which I kept at '0'. I'm wondering if there is another setup on the Nucleo that I'm not aware of.

Thanks

Ron

[TDK]

Why do you think 4095 is incorrect, as opposed to unwanted? Can you measure the signal with a probe, or ground it and recheck?

Must be a difference somewhere. If not software, then in hardware.

[Tesla DeLorean]

VDDA, VSSA, +/-VREF ?

Clocking sources

Try other​ uncommitted pins, or ones you can pull high/low etc.

[ron_w · Accepted solution]

@TDK​  and @Community member​ - It was a hardware issue in the end; the VDDA was not corrected. Now it works as required.

Thanks for the help and suggestions