[v3.4] ADC value seems too high (GIT8266O-665)

[k-tkr]

Environment

• Development Kit: ESP-WROOM-02
• IDF version (git rev-parse --short HEAD to get the commit id.): 89a3f25
• Development Env: [other] (Visual Studio + VisualGDB plugin)
• Operating System: [Windows]
• Power Supply: [USB]
• Toolchain: esp-2020r3-49-gd5524c1

Problem Description

I am playing with adc example in ESP8266_RTOS_SDK/examples/peripherals/adc/.
The displayed ADC value looks almost 10% higher than the one obtained using RTOS v3.3, which is closer to the actual voltage.
For example, when I compiled the code with vdd33_const=33 and applied 0.55V on TOUT pin and ran the example, the ADC value was around 630, while I expected 0.55 * 1023 = 563.
If I use the RTOS v3.3 SDK with the same board and the code, the output value was around 575, which was more reasonable.
I'd like to know why the ADC value between RTOS v3.3 and v3.4 are different and why the value with v3.4 is higher than expected.

Expected Behavior

ADC value should be around 560 or 570.

Actual Behavior

ADC value is 630

Steps to repropduce

Follow README.md in ESP8266_RTOS_SDK/examples/peripherals/adc/, except that I used variable resister to put 0.55V.

Code to reproduce this issue

I didn't modify the example code.

Debug Logs

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 7040, room 16
tail 0
chksum 0xf5
load 0x3ffe8408, len 24, room 8
tail 0
chksum 0x7c
load 0x3ffe8420, len 3312, room 8
tail 8
chksum 0x54
csum 0x54
I (42) boot: ESP-IDF v3.4 2nd stage bootloader
I (42) boot: compile time 16:41:03
I (43) qio_mode: Enabling default flash chip QIO
I (49) boot: SPI Speed : 40MHz
I (55) boot: SPI Mode : QIO
I (61) boot: SPI Flash Size : 2MB
I (67) boot: Partition Table:
I (73) boot: ## Label Usage Type ST Offset Length
I (84) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (96) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (107) boot: 2 factory factory app 00 00 00010000 000f0000
I (119) boot: End of partition table
I (125) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x14b4c ( 84812) map
I (167) esp_image: segment 1: paddr=0x00024b64 vaddr=0x40224b5c size=0x05a30 ( 23088) map
I (176) esp_image: segment 2: paddr=0x0002a59c vaddr=0x3ffe8000 size=0x003dc ( 988) load
I (178) esp_image: segment 3: paddr=0x0002a980 vaddr=0x40100000 size=0x00080 ( 128) load
I (192) esp_image: segment 4: paddr=0x0002aa08 vaddr=0x40100080 size=0x046c4 ( 18116) load
I (211) boot: Loaded app from partition at offset 0x10000
I (241) adc example: adc read: 630

Other items if possible

sdkconfig-debug.zip

[dsptech]

Hi,

the result is scaled of a factor 12/11 by the adc_read function (but the sdk v3.3 perform the same scaling too) .
I don't know the reason of that, and the comment inside adc_read:

// The working voltage of ADC is designed according to 1.1v. Later, the actual working voltage of ADC is increased to 1.2v, so this 
scale is added

appear to me a bit misleading. I think about a porting error from esp_idf.

Regards.

[dsptech]

you could try to get the raw (unscaled) value by calling the test_tout() function:

extern uint16_t test_tout();
adcVal = uint16_t test_tout();

(see the adc_read() body for a better reference).

[k-tkr]

Thanks.
In the code below in adc.c,
test_tout returns different values between v3.3 and v3.4, and the difference is around 10% (probably 12 / 11).
I couldn't debug inside test_tout, though.

    if (adc_handle->config.mode == ADC_READ_TOUT_MODE) {
        ret = test_tout(0);

        if (ret != 0xFFFF) {
            // The working voltage of ADC is designed according to 1.1v. Later, the actual working voltage of ADC is increased to 1.2v, so this scale is added.
            ret = ret * 12 / 11;

            if (ret > 1023) {
                // 10-bit precision ADC
                ret = 1023;
            }
        }
    }

[dsptech]

Hi, I just checked out the values returned by test_tout() (sdk to master branch, updated 15 days ago):

With WIFI ON (sta mode):
Vin: 0.567V, returned value (average): 557
Vin: 0.970V, returned value (average) 948.

With WIFI OFF (not initialized):
Vin: 0.568V, returned value (average): 602
Vin: 0.970V, returned value (average) 1022.

Strangely, the error is greater with the wifi off, but if the wifi is on the values seem ok to me.
Note: from an old post (https://bbs.espressif.com/viewtopic.php?t=34) it would appear that test_tout () treats the two conditions differently.
"The test function is in func lib , which is "test_tout" and returns 0-1024 for 0-1v.In the test func , we do care about the effect of the wifi modem already. "

[k-tkr]

Thanks.
I could get closer results if I ran adc after wifi started.
I'll use it with wifi on for now.
I'd like someone in espressif to document the behavior of test_tout (and adc_read) and fix the example if it should be used with wifi.

[dsptech]

Espressif has not a good tradition with the ADCs. With the ESP32 they literally went crazy trying to linearize (via sdk) the behavior of a wrong design.

[fuhuayanhua]

666

[goatzillax]

This is a really awkward way to handle this. The scaling should probably be detected or configurable if necessary, and railing the value to 1023 when you're putting it into a 16-bit variable anyways just causes unrecoverable data loss to the user.