[F1] How do I debug ADC / analogRead() not working?

[benwaffle]

Describe the bug
analogRead() is returning incorrect / garbage values. A multimeter between PA2 and GND shows the correct value.

To Reproduce

#include <Arduino.h>

void setup() {
    Serial.begin(923076);
    pinMode(PA2, INPUT_ANALOG);
    analogReadResolution(12);
}

void loop() {
    Serial.print(analogRead(PA2) / 4096.0 * 3.3);
    Serial.println(" V");
    delay(200);
}

Steps to reproduce the behavior:

1. Run code
2. Connect an analog input to PA2
3. See incorrect value

Expected behavior
Expected that code reads correct voltage as measured by multimeter.

Desktop:

• OS: Mac
• STM32 core version: 1.6.1
• Upload method: STLink

Board:

• Name: STM32F103C8T6 (Bluepill)

[fpistm]

Hi @benwaffle,
I've tested quickly with my BP and this seems correct.
Using Fading example with DAC of an other board connected to PA2:

Note: value change each 30ms, so I use your sketch with 15ms delay.

To debug you can try one of those methods:
https://github.com/stm32duino/wiki/wiki/How-to-debug

[fpistm]

Sorry misclicked when commented.

[fpistm]

@benwaffle any feedback?

[fpistm]

Bump

[benwaffle]

Sorry, I've been working on other things. Most recently, I was able to get stable-ish values, but still getting random spurts +/- 10 mV. How accurate can the ADC get with the arduino layer?

[AnHardt]

Mostly the noise you see is independent from the used core.
Mostly it comes down to the question: "How well is the noise protection of the analog circuitry. External. on board and inside the processor."
If you see single spikes, try to correlate them to events. Be prepared to find the source in: "Switching off the lights two rooms away."
Always think about hard- and soft-ware filtering the signals. Know and respect the Nyquist–Shannon sampling theorem and its consequences.

[AnHardt]

Arduino analogRead() is notorious for its slowness.
Always preparing the pin, setting up the ADC, initialising the conversion, busy waiting for success, reading and returning the result costs time and is the price you have to pay when you try to make the use simple. That's the Arduino concept.
If you want it fast, bypass Arduino completely and split anologRead() to its functions. With many of the ST processors you can read frequencies up to some MHz.

[AnHardt]

If i remember correctly the analog circuitry on the 'Blue Pill' is far from 'well made'.
See Known Issues at https://wiki.stm32duino.com/index.php?title=Blue_Pill

[fpistm]

@benwaffle

As @AnHardt told, analogRead() is very limited.

You can try customize on sample time:
You should follow this wiki page to redefine them:
https://github.com/stm32duino/wiki/wiki/Customize-build-options-using-build_opt.h

-DADC_SAMPLETIME=ADC_SAMPLETIME_55CYCLES_5

With one of those possible values (default: ADC_SAMPLETIME_13CYCLES_5):

Arduino_Core_STM32/system/Drivers/STM32F1xx_HAL_Driver/Inc/stm32f1xx_hal_adc.h

Lines 293 to 300 in 5cc75ca

	#define ADC_SAMPLETIME_1CYCLE_5 0x00000000U /*!< Sampling time 1.5 ADC clock cycle */
	#define ADC_SAMPLETIME_7CYCLES_5 ((uint32_t)( ADC_SMPR2_SMP0_0)) /*!< Sampling time 7.5 ADC clock cycles */
	#define ADC_SAMPLETIME_13CYCLES_5 ((uint32_t)( ADC_SMPR2_SMP0_1 )) /*!< Sampling time 13.5 ADC clock cycles */
	#define ADC_SAMPLETIME_28CYCLES_5 ((uint32_t)( ADC_SMPR2_SMP0_1 | ADC_SMPR2_SMP0_0)) /*!< Sampling time 28.5 ADC clock cycles */
	#define ADC_SAMPLETIME_41CYCLES_5 ((uint32_t)(ADC_SMPR2_SMP0_2 )) /*!< Sampling time 41.5 ADC clock cycles */
	#define ADC_SAMPLETIME_55CYCLES_5 ((uint32_t)(ADC_SMPR2_SMP0_2 | ADC_SMPR2_SMP0_0)) /*!< Sampling time 55.5 ADC clock cycles */
	#define ADC_SAMPLETIME_71CYCLES_5 ((uint32_t)(ADC_SMPR2_SMP0_2 | ADC_SMPR2_SMP0_1 )) /*!< Sampling time 71.5 ADC clock cycles */
	#define ADC_SAMPLETIME_239CYCLES_5 ((uint32_t)(ADC_SMPR2_SMP0_2 | ADC_SMPR2_SMP0_1 | ADC_SMPR2_SMP0_0)) /*!< Sampling time 239.5 ADC clock cycles */

Note: you should have at least Core version 1.6.0.

[fpistm]

No feedback since a week.
analogRead is working, value precision with analogRead is dependent to several hardware factor and of the software implementation (single ended read).
Better precision could be achieved by implementing its own read using HAL/LL, this could be part of #5

[benwaffle]

Looks like I had noise from the power supply.