vTaskDelayUntil() method not working. (IDFGH-2044)

[rajithavk]

When i try to use vTaskDelayUntil APIMethod it causes a panic abort during runtime, with the following debug output.

Untested FreeRTOS function vTaskDelayUntil
C:/msys32/home/esp-idf/components/freertos/tasks.c:1261 (vTaskDelayUntil)- assert failed!
abort() was called at PC 0x40082dba
Guru Meditation Error: Core 0 panic'ed (abort)

Backtrace: 0x40008155:0x3ffc9560 0x40007d16:0x3ffc9580 0x400f1f61:0x3ffc95a0

Rebooting...

What could be the reason, a bug in the method or something in the user application?

P.S. : #define INCLUDE_vTaskDelayUntil 1 , is in place in the RTOSconfiguration as per the freeRTOS documentation.

[Spritetm]

vTaskDelayUntil is an untested function as of now, we can't guarantee it works, so by default, it aborts rather than executing possibly buggy code. If you're still okay with using it, in menuconfig under FreeRTOS there should be an option to turn off these aborts.

[rajithavk]

Thanks Spritetm, it makes sense now. Will try it anyways disabling the aborts. Cheers.

…

On 2 March 2017 at 17:06, Jeroen Domburg ***@***.***> wrote: vTaskDelayUntil is an untested function as of now, we can't guarantee it works, so by default, it aborts rather than executing possibly buggy code. If you're still okay with using it, in menuconfig under FreeRTOS there should be an option to turn off these aborts. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#391 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJBBJgPpQxC1m7VMD9AcDFd2-dMmAixMks5rhqm9gaJpZM4MQ3-w> .

[Oliv4945]

Hi, do you have any roadmap on this function test ?

Thank you

[DavidAntliff]

@Spritetm I'd also be interested to know when this function might be elevated from "untested" to supported - it's a very useful function for periodic tasks.

[Oliv4945]

@DavidAntliff, it is now tested, see 637ba2e

[davctv]

Hi,
I'm still haveing some issue with vTaskDelayUntil API, in particular it fails asserting

configASSERT( uxSchedulerSuspended[ xPortGetCoreID() ] == 0 );

I'm using v3.1rc2 (22da5f6) release

`C:/msys32/home/Davide/esp/esp-idf/components/freertos/tasks.c:1343 (vTaskDelayUntil)- assert failed!
abort() was called at PC 0x40092207 on core 1

Backtrace: 0x40096260:0x3ffdbfa0 0x40096403:0x3ffdbfc0 0x40092207:0x3ffdbfe0 0x400ed68d:0x3ffdc000

Entering gdb stub now.
$T0b#e6
`

I have also got in another test a quite same assert fail for vTaskDelay function

`C:/msys32/home/Davide/esp/esp-idf/components/freertos/tasks.c:1443 (vTaskDelay)- assert failed!
abort() was called at PC 0x400922ad on core 0

Backtrace: 0x40096260:0x3ffe3460 0x40096403:0x3ffe3480 0x400922ad:0x3ffe34a0 0x400eec3f:0x3ffe34c0

Entering gdb stub now.
$T0b#e6`

How can I avoid this assert fail?

Thanks

[ammaree]

@Spritetm

I am also getting a crash with this function, basic coredump details pasted below. The unusual bit here is that it shows for the parameters in the last 2 function calls. The delay would normally be between 1-10 ticks (mSec in my case) Is this correct?

`espcoredump.py v0.2-dev

==================== ESP32 CORE DUMP START ====================

================== CURRENT THREAD REGISTERS ===================
pc 0x4008c70d 0x4008c70d <vTaskDelayUntil+209>
lbeg 0x4000c2e0 1073791712
lend 0x4000c2f6 1073791734
lcount 0xffffffff 4294967295
sar 0x11 17
ps 0x60520 394528
threadptr
br
scompare1
acclo
acchi
m0
m1
m2
m3
expstate
f64r_lo
f64r_hi
f64s
fcr
fsr
a0 0x400845c0 1074283968
a1 0x3ffd3be0 1073560544
a2 0x0 0
a3 0x2f07dd0 49315280
a4 0x60023 393251
a5 0x3ffd3ca4 1073560740
a6 0x0 0
a7 0x0 0
a8 0x8008c70d -2146908403
a9 0x3ffd3bc0 1073560512
a10 0x0 0
a11 0x2f07dd0 49315280
a12 0x0 0
a13 0x3ffbfaec 1073478380
a14 0x0 0
a15 0x3ffbfac4 1073478340

==================== CURRENT THREAD STACK =====================
#0 0x4008c70d in vTaskDelayUntil (pxPreviousWakeTime=, xTimeIncrement=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/tasks.c:1422
#1 0x400845c0 in vTaskActuator (pvPara=) at C:/Dropbox/devs/ws/z-components/actuators/actuators.c:358

======================== THREADS INFO =========================
Id Target Id Frame
18 process 17 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffc0eb8, pvBuffer=0x3ffc1f60, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
17 process 16 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffc2240, pvBuffer=0x3ffc36a0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
16 process 15 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffaea30, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
15 process 14 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffaff40, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
14 process 13 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffafd70, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
13 process 12 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffbd3b8, pvBuffer=0x3ffce440, xTicksToWait=200, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
12 process 11 0x4008c70d in vTaskDelayUntil (pxPreviousWakeTime=, xTimeIncrement=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/tasks.c:1422
11 process 10 0x4008c70d in vTaskDelayUntil (pxPreviousWakeTime=, xTimeIncrement=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/tasks.c:1422
10 process 9 0x4008ecc4 in prvProcessTimerOrBlockTask (xNextExpireTime=, xListWasEmpty=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/timers.c:588
9 process 8 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffbff50, pvBuffer=0x3ffc0bf0, xTicksToWait=100, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
8 process 7 0x4008c77e in vTaskDelay (xTicksToDelay=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/tasks.c:1490
7 process 6 0x4008c77e in vTaskDelay (xTicksToDelay=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/tasks.c:1490
6 process 5 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffbd6d8, pvBuffer=0x3ffcd5b0, xTicksToWait=100, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
5 process 4 0x400d7f9a in esp_vApplicationIdleHook () at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/esp32/freertos_hooks.c:64
4 process 3 0x400d7f9a in esp_vApplicationIdleHook () at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/esp32/freertos_hooks.c:64
3 process 2 0x4000bff0 in ?? ()
2 process 1 _xt_lowint1 () at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos\xtensa_vectors.S:1079

• 1 0x4008c70d in vTaskDelayUntil (pxPreviousWakeTime=, xTimeIncrement=) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/tasks.c:1422

======================= ALL MEMORY REGIONS ========================
Name Address Size Attrs
.rtc.text 0x400c0000 0x0 RW
.rtc.data 0x50000000 0x2000 RW A
.rtc_noinit 0x50002000 0x0 RW
.iram0.vectors 0x40080000 0x400 R XA
.iram0.text 0x40080400 0x12ab0 R XA
.dram0.data 0x3ffb0000 0x4b0c RW A
.noinit 0x3ffb4b0c 0x0 RW
.flash.rodata 0x3f400020 0x2a1b4 RW A
.flash.text 0x400d0018 0x97c00 R XA
.coredump.tasks.data 0x3ffd3ca4 0x170 RW
.coredump.tasks.data 0x3ffd3b20 0x17c RW
.coredump.tasks.data 0x3ffd29b4 0x170 RW
.coredump.tasks.data 0x3ffd2000 0x9ac RW
.coredump.tasks.data 0x3ffcc6e8 0x170 RW
.coredump.tasks.data 0x3ffcbf50 0x790 RW
.coredump.tasks.data 0x3ffbe6f0 0x170 RW
.coredump.tasks.data 0x3ffbe580 0x168 RW
.coredump.tasks.data 0x3ffbee68 0x170 RW
.coredump.tasks.data 0x3ffbed00 0x160 RW
.coredump.tasks.data 0x3ffcd760 0x170 RW
.coredump.tasks.data 0x3ffcd480 0x2d8 RW
.coredump.tasks.data 0x3ffd05cc 0x170 RW
.coredump.tasks.data 0x3ffd0430 0x194 RW
.coredump.tasks.data 0x3ffd1044 0x170 RW
.coredump.tasks.data 0x3ffd0ec0 0x17c RW
.coredump.tasks.data 0x3ffc0c8c 0x170 RW
.coredump.tasks.data 0x3ffc0aa0 0x1e4 RW
.coredump.tasks.data 0x3ffbf8dc 0x170 RW
.coredump.tasks.data 0x3ffbf750 0x184 RW
.coredump.tasks.data 0x3ffd342c 0x170 RW
.coredump.tasks.data 0x3ffd32b0 0x174 RW
.coredump.tasks.data 0x3ffced54 0x170 RW
.coredump.tasks.data 0x3ffcebc0 0x18c RW
.coredump.tasks.data 0x3ffce5dc 0x170 RW
.coredump.tasks.data 0x3ffce310 0x2c4 RW
.coredump.tasks.data 0x3ffafdcc 0x170 RW
.coredump.tasks.data 0x3ffbc2b0 0x180 RW
.coredump.tasks.data 0x3ffbc83c 0x170 RW
.coredump.tasks.data 0x3ffbc6b0 0x184 RW
.coredump.tasks.data 0x3ffafa90 0x170 RW
.coredump.tasks.data 0x3ffaf900 0x188 RW
.coredump.tasks.data 0x3ffc373c 0x170 RW
.coredump.tasks.data 0x3ffc3570 0x1c4 RW
.coredump.tasks.data 0x3ffc2018 0x170 RW
.coredump.tasks.data 0x3ffc1e60 0x1b0 RW `

[chegewara]

Is it possible you have some heap corruption issue or something? Because last few xTicksToWait= is set to 4294967295 which is portMAX_DELAY (i think). If im not wrong then it will wait forever.

18 process 17 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffc0eb8, pvBuffer=0x3ffc1f60, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
17 process 16 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffc2240, pvBuffer=0x3ffc36a0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
16 process 15 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffaea30, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
15 process 14 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffaff40, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591
14 process 13 0x4008e4d1 in xQueueGenericReceive (xQueue=0x3ffafd70, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at C:/Dropbox/devs/ws/z-sdk/esp-idf/components/freertos/queue.c:1591

Also address of pvBuffer is 0x0.

[ammaree]

xTicksToWait=4294967295 is portMAX_DELAY and valid, possibly not a problem there.

Without knowing the specific tasks I cannot comment on the pvBuffer=0x0 since a number of macros call xQueueGenericReceive()

[davctv]

Hi,
I'm still having issue with assert on vTaskDelay

During weekend I have 3 devices on test and all of them they blocked due to assertion failed on vTaskDelay (same task for all of them). Here is the gdb backtrace

`C:/msys32/home/Davide/esp/esp-idf/components/freertos/tasks.c:1443 (vTaskDelay)- assert failed!
abort() was called at PC 0x400925fd on core 1

Backtrace: 0x40096530:0x3ffdcf00 0x400966d3:0x3ffdcf20 0x400925fd:0x3ffdcf40 0x400ee57c:0x3ffdcf60

Entering gdb stub now.
$T0b#e6

0x40096530 in invoke_abort ()
at C:/msys32/home/Davide/esp/esp-idf/components/esp32/panic.c:140
140 *((int *) 0) = 0;
(gdb) bt
#0 0x40096530 in invoke_abort ()
at C:/msys32/home/Davide/esp/esp-idf/components/esp32/panic.c:140
#1 0x400966d6 in abort ()
at C:/msys32/home/Davide/esp/esp-idf/components/esp32/panic.c:149
#2 0x40092600 in vTaskDelay (xTicksToDelay=20)
at C:/msys32/home/Davide/esp/esp-idf/components/freertos/tasks.c:1443
#3 0x400ee57f in COMMAND_state_machine (pvParameters=)
at C:/msys32/home/Davide/esp/Avior_ESP32_WiFi/main/command.c:3059`

I can't understand what is the root of the assertion failed.
Is it caused by period too short (in my case 20ms)?
Should I pin the task to a specific core?

Should I enable coredump to give more details?

I'm working on esp-idf v3.1

Thanks

[stuarthatchbaby]

We're seeing the same assertion failure on 3.3:

/home/stuart/esp/esp-idf-v3.3-rc/components/freertos/tasks.c:1340 (vTaskDelayUntil)- assert failed!
abort() was called at PC 0x400970f1 on core 0
ELF file SHA256: ed66a63567798d37e4441146b46e2ee6db61b0e03fc5cd18f81c58d21e832e85
Backtrace: 0x4008eef7:0x3ffd4d30 0x4008f20d:0x3ffd4d50 0x400970f1:0x3ffd4d70 0x400f48f1:0x3ffd4d90 0x400f4914:0x3ffd4dd0
Rebooting...

Did this issue get closed with a resolution?

[liuzfesp]

Hi @stuarthatchbaby, could you help to paste the backtrace of this assert here, commands to get the backtrace:

xtensa-esp32-elf-addr2line -piaf -e *.elf 0x4008eef7:0x3ffd4d30 0x4008f20d:0x3ffd4d50 0x400970f1:0x3ffd4d70 0x400f48f1:0x3ffd4d90 0x400f4914:0x3ffd4dd0

You can choose to paste the *elf here, then we can get the backtrace for analysis.

[stuarthatchbaby]

I did so in #4230