Skip to main content
Visitor II
January 19, 2022
Solved

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

  • January 19, 2022
  • 3 replies
  • 1422 views

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

    This topic has been closed for replies.
    Best answer by ron_w

    @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

    3 replies

    Super User
    January 20, 2022

    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.

    Graduate II
    January 20, 2022

    VDDA, VSSA, +/-VREF ?

    Clocking sources

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

    ron_wAuthorAnswer
    Visitor II
    January 27, 2022

    @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