ESP32 ULP ADC sampling glitch during wakeup

[dmarcos]

Hi,

I'm trying to sample a signal relatively fast and continuously with minimum power consumption using the ESP32's ULP.

For now, the main program configures the ADC for ULP sampling and goes to sleep. It also configures the ULP wakeup timer for the required sampling period.

Every time the ULP wakeup timer expires the ULP wakes up, takes a sample and stores it in one of the two available sample buffers (I use double buffering). Whenever a buffer is full, it signals the main cores to wake up.

The main program wakes up, checks which of the two buffers is in use and dumps the other through the UART very fast, going to deep sleep again after that. The ULP just keeps running forever alternatively filling buffers and signaling the main cores to dump them.

If I change the ADC signal for an internally generated sawtooth (i.e filling the buffer with that signal instead of reading the ADC) I can check that there's no sample loss due to timing, meaing there's no race conditions in the sampling scheme and everything is well timed (the main core takes about 10 times less time for dumping a buffer than the ULP takes to fill it). Also, injecting a signal I can see that indeed no samples are lost and I get a clean signal, except that the first ~50ms of samples after main processor wake up get corrupted and are always 4096.

I mean,
-the ULP wakes up the main processor after a buffer is full, and keeps filling the second buffer in the background
-There's no sample loss, in the sense that a sample is taken for every period and all of them are dumped in time when the main processor wakes
-However, the first 50ms worth of samples are 4096 (i've checked that it's indeed time dependent and not sample-dependent, if I reduce sampling frequency simply more samples get corrupted)
-I've checked that it's a wake-up issue. If I never put the main cores in deep-sleep and instead keep them in a delay loop waiting for the ULP to finish writing a buffer to dump it i don't get this issue, I get a perfect signal with all samples correct and no sample loss.
-The ADC is configured once and only once. I mean, this is how the first lines of app_main() look like:

Code: Select all

void app_main()
{
	uint16_t sample;
    esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();
    if (cause != ESP_SLEEP_WAKEUP_ULP) {
       		 init_ulp_program();
		start_ulp_program();
    } else {
    //ULP wakeup, do the buffer dumping thingie, never call Init or start ulp again, ever
    }

And the init function does this, among other things:

Code: Select all

    adc1_config_channel_atten(ADC1_CHANNEL_6, ADC_ATTEN_DB_11);
    adc1_config_width(ADC_WIDTH_BIT_12);
    adc1_ulp_enable();

So, there's something in the wake-up process that messes the ADC for ~50ms. I kind of expected it, actually I didn't even expect the ULP to be capable what it's doing right now, but even if this is so close to work this issue is a showstopper. Considering that every time the ESP32 main cores wake up it's sort of like a reset, with the second stage bootloader doing its things and main memory resetting (i'm using the IDF here), do you have any idea on where the issue might come from?

Thanks,
David

[ESP_igrr]

Most likely this is the 2nd stage bootloader switching ADC to a different mode to feed some entropy into the PRNG: https://github.com/espressif/esp-idf/bl ... dom.c#L115. can you confirm that by disabling the calls to bootloader_random_enable/bootloader_random_disable in the bootloader?

[dmarcos]

Most likely this is the 2nd stage bootloader switching ADC to a different mode to feed some entropy into the PRNG: https://github.com/espressif/esp-idf/bl ... dom.c#L115. can you confirm that by disabling the calls to bootloader_random_enable/bootloader_random_disable in the bootloader?

Yes, that was it. Working perfectly now, thank you.

[ESP_igrr]

Chances are that since you are using ADC1, and "bootloader_random" function is using ADC2, the glitch can be removed. We are looking into this.

[davidtaille]

Hi,

@ ESP_igrr : have you had a chance to sort this out and remove the glitch ?

I'm running into a similar issue I think, where ADC1 returns 0xFFF on a pin that"s kept at constant level approximately 30ms before esp_wake_deep_sleep() is run.
(I'm spotting it by having ulp toggling a few pins to flag up various conditions and using an oscilloscope to look at pins state.)

If the glitch cannot be avoided, is there a way to tell from the ULP that wake up is in progress ?
The only way around i've found so far is to use the esp_wake_deep_sleep() to set 1 in an RTC_SLOW_MEM word, and have the ULP check for this value (and then avoid making any measurement on the ADC). Of course I put the word back to 0 first thing in app code.

Thanks for your help.

Best,
David