Answers checklist.

  • [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.


Operating System used.


How did you build your project?

Command line with Make

If you are using Windows, please specify command line type.


Development Kit.


Power Supply used.


What is the expected behavior?

not crash

What is the actual behavior?

I have an example similar to examples/peripherals/adc/continuous_read, except my interrupt task sends a message via xQueueSendFromISR: xQueueSendFromISR(queu, &data, 0)

I get the following when my main calls adc_continuous_stop

assert failed: xQueueGenericSend queue.c:833 (pxQueue->pcHead != ((void *)0) || pxQueue->u.xSemaphore.xMutexHolder == ((void *)0) || pxQueue->u.xSemaphore.xMutexHolder == xTaskGetCurrentTaskHandle())

Backtrace: 0x40082315:0x3ffef990 0x4008f9d1:0x3ffef9b0 0x40099d41:0x3ffef9d0 0x4008fe11:0x3ffefb00 0x40083ab4:0x3ffefb40 0x401aafb7:0x3ffefb70 0x401793ad:0x3ffefba0 0x400db63e:0x3ffefbd0 0x4010c5e2:0x3ffefc00 0x40107c98:0x3ffefc30 0x40107cdb:0x3ffefc50 0x401027b1:0x3ffefc70 0x40108300:0x3ffefcf0 0x40108409:0x3ffefd10 0x40108e44:0x3ffefd40 0x40108e91:0x3ffefd60 0x40108be0:0x3ffefd80 0x40108fb2:0x3ffefda0 0x401091d6:0x3ffefde0 0x4011baed:0x3ffefe30 0x4010c5e2:0x3ffefe50 0x40107679:0x3ffefe80 0x40107ca9:0x3ffeff10 0x40107cc5:0x3ffeff30 0x401027b1:0x3ffeff50 0x40108300:0x3ffeffd0 0x401165c5:0x3ffefff0 0x4013e230:0x3fff0020 0x40144021:0x3fff0050 0x401441cf:0x3fff00b0 0x40144d3b:0x3fff00e0 0x40131745:0x3fff0100 0x401317b1:0x3fff0120 0x40147fd7:0x3fff0140 0x40148029:0x3fff0160 0x4014090a:0x3fff0180 0x400ecb1b:0x3fff01b0 0x40082315: panic_abort at /home/V5/esp/esp-idf/components/esp_system/panic.c:451

0x4008f9d1: esp_system_abort at /home/V5/esp/esp-idf/components/esp_system/port/esp_system_chip.c:84

0x40099d41: __assert_func at /home/V5/esp/esp-idf/components/newlib/assert.c:81

0x4008fe11: xQueueGenericSend at /home/V5/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:833 (discriminator 8)

0x40083ab4: lock_release_generic at /home/V5/esp/esp-idf/components/newlib/locks.c:192 (inlined by) _lock_release at /home/V5/esp/esp-idf/components/newlib/locks.c:198

0x401aafb7: adc_lock_release at /home/V5/esp/esp-idf/components/esp_hw_support/adc_share_hw_ctrl.c:130 (discriminator 2)

0x401793ad: adc_continuous_stop at /home/V5/esp/esp-idf/components/esp_adc/adc_continuous.c:399

Next backtrace is from my call to adc_continuous_stop

BTW, I tried to remove the callback prior to stopping and then sleep for a second adc_continuous_evt_cbs_t cbs = {0}; adc_continuous_register_event_callbacks(handle, &cbs, 0); sleep adc_continuous_stop(handle)

But I then get: E (60083) adc_continuous: adc_continuous_register_event_callbacks(578): ADC continuous mode isn't in the init state, it's started already

Steps to reproduce.

Let me know if you want my complete code, but it will require some configuration.

Debug Logs.

No response

More Information.

I could be doing something wrong, but it looks like a bug.


I had a similar issue using vTaskNotifyGiveFromISR(&someTask,...) in a continuous conversion done callback function. Have not found any good documentation on this -- it's mainly a FreeRTOS thing -- but it appears that you must call the start and stop continuous sampling functions in the same task. If you don't it'll throw a hissy fit and panic. I.e you can't call adc_continuous_stop in the conversion done ISR, nor can you call it in any other task than the one where adc_continuous_start was called. At least that is my understanding of things.

What worked for me was to start a task, in that task call adc_continuous_start at the beginning, then run a while loop where I process the data. Here you can also call adc_continuous_stop/start when needed and it shouldn't crash.


OK, thank you. I have done some preliminary testing using one task for start/stop and I have no asserts.

However; it is still a bug since this limitation needs to be documented.


Seems to me you should be using a binary semaphore instead of a mutex.

© 2022 - All rights reserved.