analogReadMilliVolts returns wrong values on ESP32-S2

[newHeiko]

Hardware:

Board: ESP32-S2-WROOM
Core Installation version: idf-release/v4.2 (current HEAD: beedeea)
IDE name: Arduino IDE
Flash Frequency: 40Mhz
PSRAM enabled: no
Upload Speed: 921600 via USB
Computer OS: Linux

Description:

#4386 is still open in current HEAD of idf-release/v4.2 branch.

I have my own PCB with an ESP32-S2-WROOM and a 10k-potentiometer connected to pin 9. My multimeter shows ~990mV and the ESP32-S2 will read between 1411mV and 1418mV.

When I change the potentiometer, the readout changes, with a roughly constant factor between the measurement and the readout.

Please let me know if there is anything I can do to debug / test.

Heiko

Sketch:

void setup() {
  Serial.begin(115200);
  delay(5000);
  uint32_t analogValue = analogReadMilliVolts(9);
  Serial.println(String("Read ") + analogValue + " mV at time " + millis());
  delay(5000);
  analogValue = analogReadMilliVolts(9);
  Serial.println(String("Read ") + analogValue + " mV at time " + millis());
  delay(5000);
  analogValue = analogReadMilliVolts(9);
  Serial.println(String("Read ") + analogValue + " mV at time " + millis());
}

void loop() {
}

Debug Messages:

ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0xa (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3ffe6100,len:0x8
load:0x3ffe6108,len:0x620
load:0x4004c000,len:0xa40
load:0x40050000,len:0x284c
entry 0x4004c190
[   648][D][esp32-hal-cpu.c:204] setCpuFrequencyMhz(): PLL: 480 / 3 = 160 Mhz, APB: 80000000 Hz
Read 1415 mV at time 5661
Read 1413 mV at time 10661
Read 1415 mV at time 15661

[lbernstone]

Can you turn on verbose debugging and post the relevant section, particularly about the vref calibration.

[newHeiko]

This may be a stupid question, but how do I do that? I already had set "Core level debug" do "Verbose" in the Tools-menu of the Arduino IDE.

I've tried:

• Add esp_log_level_set("*", ESP_LOG_VERBOSE); to my sketch
• Add Serial.setDebugOutput(true); to my sketch
• Add #define CONFIG_ARDUHAL_LOG_DEFAULT_LEVEL 5 and
• Add #include "esp32-hal-log.h" to my sketch
• Changed CONFIG_ARDUHAL_LOG_DEFAULT_LEVEL and CONFIG_LOG_DEFAULT_LEVEL to 5 in tools/sdk/esp32s2/include/config/sdkconfig.h

None of those change the debug output I've included above.

Thanks,
Heiko

[newHeiko]

Addendum: From the code, it looks like there is just no characterization (and therefore no logging) going on for ESP32-S2:

arduino-esp32/cores/esp32/esp32-hal-adc.c

Line 172 in beedeea

#if CONFIG_IDF_TARGET_ESP32

edit: If I add a call to log_v just before the return in that function, I get an output. So I'm sorry, there is no more debug output then what I showed above.

Heiko

[lbernstone]

Well, that's a sort of answer 😄 . The calibration for s2 probably wasn't available when this code was written. Once work begins again on v2.0, it will get added. Change the title of the issue to [2.0.0] Add ADC calibration for ESP32-S2

[newHeiko]

Seems like it's more than calibration - if I'm not entirely mistaken, calibration should fix the last 10% or so?

Just tested with analogRead and the adc1_get_raw-function from the ESP-IDF - the raw values don't make sense either. Reading 1.65V (3.3V/2) with 11dB attenuation results in raw values around 5200 where I'd expect 1.65V / 1.1V (Vref measured) / 3.54 (11dB) * 8191 ~= 3200. So probably also a bug in the docs describing attenuation.

Anyhow, rename as you see fit. I'll be rolling my own calibration.

Heiko

[kevinjwalters]

CircuitPython uses the SDK to set gain to -11dB but I calculated the actual value as -7.5dB based on the ADC being unable to go above 2.6V.

I did some comparison of different ADCs on: Adafruit Forums: Feather ADC comparison including 2.6V limited ESP32-S2.

It's not a perfect testbed because they are just measuring the SAMD21 DAC output but it clearly shows some of the deficiencies of Espressif ADCs. The failed quest for full range (0-3.3V) is chronicled on: adafruit/circuitpython#3785

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.