Hi @davdav
I don't source of the problem is due to the delay duration or the number of tasks. If your application doesn't call
vTaskSuspendAll(), I see two possibilities that can cause this issue.
1) Bug with IDF functions that internally call
vTaskSuspendAll()
The assert in
vTaskDelay() checks to see if the
uxSchedulerSuspended of the current core is set. The only functions that change
uxSchedulerSuspended are
vTaskSuspendAll() and
xTaskResumeAll(). If your application code does not call
vTaskSuspendAll() directly, the only other possibility is that some other IDF function that internally calls
vTaskSuspendAll() is being called in some way by your application.
The current places where
vTaskSuspendAll() is used are as follows
- FreeRTOS Event Groups
- FreeRTOS Timer Service Task (Daemon Task)
- Multiple SPI Flash functions that internally call
spi_flash_disable_interrupts_caches_and_other_cpu()
-
esp_restart()
When a function calls
vTaskSuspendAll(), the calling function is not supposed to yield or be preempted until it calls
xTaskResumeAll(). Therefore, I don't see how a function could have called
vTaskSuspendAll() and then some how manage to switch context to your application task which calls
vTaskDelay(), unless there's a bug in scheduling.
It'll be helpful if you could check if any of your application tasks use the features listed above. A description of what your tasks are doing, their priorities and core affinities, and your application's SDK config would also be helpful.
2) Memory corruption that overwrites
uxSchedulerSuspended[portNUM_PROCESSORS]
It could be possible that
uxSchedulerSuspended is overwritten due to memory corruption. But finding the source of memory corruption could be difficult. I suggest you either use JTAG or software to set a watchpoint on
uxSchedulerSuspended (see
Heap Memory Debugging)