adc_continuous_stop cannot be called from other tasks than the one it creates it (IDFGH-13122)

filzek commented 3 months ago

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.

v5.2.2-175-g401816eac0

Espressif SoC revision.

Esp32 v3

Operating System used.

Windows

How did you build your project?

Command line with Make

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

None

Development Kit.

Esp32 Wrover

Power Supply used.

External 5V

What is the expected behavior?

Be able to run the adc_continuous_stop anywhere in the system as the HANDLE is the true related manager of the adc continuous run.

What is the actual behavior?

When trying to call the adc_continuous_stop in a task other than the one that is created with it adc_continuous_start it draws a problem and crash with xTaskPriorityDisinherit .

Steps to reproduce.

Simple build the the adc_continuous_start from one task, and try to adc_continuous_stop from another task it draws the problem.

Debug Logs.

No response

More Information.

No response

listout commented 3 months ago

Possible duplicate of https://github.com/espressif/esp-idf/issues/13484.

There is a workaround in the linked issue

Icarus113 commented 3 months ago

When trying to call the adc_continuous_stop in a task other than the one that is created with it adc_continuous_start it draws a problem and crash with xTaskPriorityDisinherit .

Inside the API there's a mutex. May I know why the stop API is used in another task instead of the task which calls the start API?

filzek commented 3 months ago

Hi @Icarus113,

Designing a complex system using microkernel approaches, similar to Linux, can indeed streamline resource management and minimize memory fragmentation. Here’s a breakdown and a proposed solution for handling ADC operations in such a system, especially when considering the concurrency issues you mentioned:

System Design Overview

1. Microkernel Core: This core manages all hardware resources centrally but unlike a monolithic kernel, it doesn't directly perform operations. Instead, it delegates to specific driver modules.

2. Resource Enablement: Through the microkernel, enable or disable hardware resources like ADC, DAC, etc. This approach ensures that all parts of the system can operate without direct dependency on the core for routine operations but can request resource changes centrally.

3. Task and Function Dispatch: The microkernel controls task creation and function dispatch, ensuring efficient task management without becoming a bottleneck.

4. Action Controls: While the kernel handles the initiation and stopping of tasks, actual enable/disable actions can be issued from any part of the system, ensuring flexibility.

ADC Operation and Concurrency Issue Problem: When ADC continuous reading is concurrent with SPI Flash writing, especially involving PSIRAM, the system crashes due to resource contention.

Proposed Solution:

1. Handle and Mutex Usage: Instead of using a mutex within the ADC API (which currently leads to problems due to its handling of resource locks), switch to a more granular handle-based control system.

- Configurable Handle (CFG Handle): Each ADC operation gets a dedicated handle with configurable properties. - Monolithic Flag: This flag within the CFG Handle determines if the ADC handle can be stopped or adjusted by other tasks. This can be toggled to allow more flexible control over ADC tasks, making them independent or dependent on the calling task's lifecycle.

Workaround for ADC and SPI Flash Concurrency

1. Temporarily Disable ADC: Before initiating SPI Flash operations, programmatically disable ADC readings. This can be managed via the CFG Handle. 2. Task Notification System: Implement a notification system where the task performing SPI Flash operations can send a signal to temporarily halt ADC operations. 3. Resume ADC Post File Operations: Once the file operations are complete, the ADC can be safely resumed.

System-Wide Benefits

- Reduced Memory Fragmentation: By centralizing control but decentralizing execution, memory usage is more efficient and less prone to fragmentation.

Enhanced Flexibility: Actions to control resources like enabling/disabling and stopping tasks can be executed from anywhere in the system, allowing for dynamic response to operational conditions.

Conclusion This design leverages the strengths of a microkernel for efficient resource management while maintaining the flexibility needed in complex embedded systems. The specific handling of ADC and SPI Flash operations addresses the concurrency issue, ensuring system stability and data integrity.

Implementing these changes should help stabilize your system against the concurrency issues you've encountered, particularly in high-data-rate scenarios involving ADC and memory operations.

espressif / esp-idf