[HELP] ESP32-S3 Don't work ADC

[shizacat]

Description

Hello. I trying to read value from ADC, but have something problem.

1. Added this code, without it don't get anything. It always returns the same value, regardless of the applied voltage to the pin.

  /* Select RTC control */
  regval = getreg32(SENS_SAR_MEAS1_MUX_REG);
  regval &= ~(SENS_SAR1_DIG_FORCE_M);
  // regval |= (0 << SENS_SAR1_DIG_FORCE_S);  // 1: Select digital control; 0: Select RTC control.
  putreg32(regval, SENS_SAR_MEAS1_MUX_REG);

in here: https://github.com/apache/nuttx/blob/master/arch/xtensa/src/esp32s3/esp32s3_adc.c#L441

2. After, I got the value from ADC, but happed something strange, the voltage on pin drop down.
   I understand what happen. Please help!

Board: ESP32-S3 dev kit

Board connect

The voltage on pin before read.

The voltage on pin after read.

Configuration: ./tools/configure.sh -m esp32s3-devkit:adc

Console

# on pin 3V before read
nsh> adc -n 2
Sample:
1: channel: 0 value: 1727
Sample:
1: channel: 0 value: 1534
nsh>

Verification

• I have verified before submitting the report.

[acassis]

@shizacat thanks for finding this issue and reporting it here! @tmedicci @fdcavalcanti @eren-terzioglu

[fdcavalcanti]

Thanks for the report. I'll look into this.

[fdcavalcanti]

@shizacat Please share what NuttX version you are running.

• Does the voltage issue happen on other pins?
• It goes low only during reading or does it go back up again, after you are done sampling?

[shizacat]

@fdcavalcanti
NuttX version: 12.7.0

Does the voltage issue happen on other pins?

Yes, I tested on ADC Channel 0,1,2, the voltage behavior on the pin was the same.

It goes low only during reading or does it go back up again, after you are done sampling?

It stays low while the device is open.

Steps:

• Restart device, the voltage on pin ch0 is set to 3 V.
• call 'adc -p /dev/adc0 -n 5', in this moment voltage drop down to 1.4V, and it remains in this state. I can slight change the voltage on pin by resistor (but don't to zero).
• then I open the next device (old, as I think is closed). call 'adc -p /dev/adc1 -n 5', The voltage in channel 0 rises again to 3 V, and I can change it in the range from 0 to 3 V. But on channel 1 the voltage drop down to 1.4V
• the same is true for Channel 2

[fdcavalcanti]

@shizacat thanks. I did a quick test here without your RTC control modifications.

The voltage is indeed returning a bad value. If I hold the ADC pin to 3v3 or GND I can see it changes 1 or 2 mV, which is not ok. Maybe some bad equation or calibration related? Also, measured with a voltmeter and it is not dropping as you showed.

The difference when using the RTC code you suggested is that maybe something is not being properly shutdown, and it is externalizing that 1.4 V value, which is different than halving the input voltage. Weird anyway.

Unfortunately we are not supporting register-based drivers anymore, we are now using the HAL approach. So I won't be able to go investigate this issue further.
I'll add the ADC to our list of upgrades with the HAL, but if anyone on the community wants to take this on, please feel free.

[acassis]

@fdcavalcanti maybe @nuttxs could take a look, he added this driver.

As I remember the idea was to keep Xtensa as proper driver and new RISC (ESP32-C3/C6, etc) will use the HAL.

[shizacat]

@fdcavalcanti Thank you!

[shizacat]

@acassis
Hello, I want to try to change the implementation of the ADC driver to work through components/hal.
But I encountered difficulties.
I thought to take a ready-made component esp-hal-3rdparty/components/esp_adc, in particular adc_oneshot.c.

It is not so easy to build - adc_oneshot.c.

• error in include
• methods heap_caps_calloc
• undeclared defines MALLOC_CAP_DEFAULT, RTC_GPIO_MODE_DISABLED
• critical sections

esp-hal-3rdparty - how can I make changes there (send MR).

There are also questions about the changes themselves, example:

• portENTER_CRITICAL vs portENTER_CRITICAL_SAFE (what should be used for Nuttx - spin_lock_irqsave, spin_lock, enter_critical_section).
• and other questions

And in general, I'm not sure if I'm moving in the right direction.

Could you help, how to do it correctly (may be it is not necessary to do this and someone is already doing it).
Use components directly, or do you need some low-level 'hal' methods, but then it seems like it will be a repetition of the component. Maybe this doesn't need to be done at all due to the license or the project architecture.

[fdcavalcanti]

Hi @shizacat. That's would be a nice contribution!

To accomplish this, you need to use other similar features as example. Since you are using Xtensa, take a look at arch/xtensa/src/common/espressif and use those as reference. RMT, QEncoder, PCNT, MCPWM are all good HAL-based features that you can use as example.

Looking at the adc_oneshot.c and comparing to the features I mentioned, you will see we don't use the adc_oneshot.c directly. We only use the HAL functions (such as adc_oneshot_hal_setup(), adc_oneshot_hal_convert()) available, and we implement the content of adc_oneshot.c in the NuttX way.

A similar question was asked regarding power management a couple of months ago. @tmedicci answered this on this thread.
Please take a look at the start where the HAL is discussed.

You will see that we use a specific branch of the esp-hal-3rdparty repository. In there, portENTER_CRITICAL and portENTER_CRITICAL_SAFE are dealt with using little maneuvers such as #ifdef __NuttX__ to support the proper functions. See this on line 28 as example.

Please take a look at the links I showed and use one of the features as an example.
Feel free to share any other questions here.

[acassis]

@shizacat I think if you get it working without using the 3rd-party-hal it will be better. ESP32 support was implemented in the standard registers description, as Greg Nutt did for all others MCUs. Using the HAL is good because Espressif can add support faster to new chips on NuttX, but is has this drawbacks, as it adds an external dependency.