# Strange behavior of vTaskDelay() when optimization is turned off (O0) **URL:** \ **Category:** Kernel\ **Created:** [April 18, 2020, 5:16am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562 "2020-04-18T05:16:41Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 5:16am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/1 "2020-04-18T05:16:42Z")
I am building a project for `STM32` based on `libopencm3` and `FreeRTOS` with one task: blinking LED with a delay. ```auto void vApplicationStackOverflowHook(TaskHandle_t *pxTask, signed portCHAR *pcTaskName) { (void)pxTask; (void)pcTaskName; gpio_set(GPIOD, GPIO14); while (1); } void vLedToggle(void *args) { while (1) { gpio_toggle(GPIOD, GPIO12); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { clock_setup(); gpio_setup(); xTaskCreate(vLedToggle, "vLedToggle", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL); vTaskStartScheduler(); return 0; } ``` Building is done with optimization disabled. As a result, incomprehensible functioning of the software (yes, the inclusion of optimization solves the problem, but I want to understand what is the reason for this behavior). I noticed a strange thing: initially the LED is off, after the microcontroller starts up, it turns on, but it no longer goes out. It turns out that the program falls into `blocking_handler()` due to Hard Fault (`blocking_handler()` - standard libopencm3 stub for specific exceptions). But why this happens is not clear. I debug in `VSCode` using `JLink`. Unfortunately, the call did not find anything interesting on the stack (the last function is my attempt to get information about the error; removing the written code, the program will appear in `blocking_handler()`): ![6sLfV](https://d2v6vdsk2p900z.cloudfront.net/original/1X/3988203f071792d106cefa0a3cfd855b32d954e7.png) The second strange thing: if put a breakpoint at the beginning of the task, step through all the functions (with enter in each), everything works perfectly. No interrupts are used. The OS is configured according to the documentation and examples (I can publish the contents of the file, if necessary; `configASSERT()` is defined). I tried to get the contents of the registers according to the instructions on the `FreeRTOS` website, but to no avail - `pc`, for example, contains: `0xA5A5A5A4`. (If replace `vTaskDelay()` with a banal cycle, then everything works.) What could be the problem and how to deal with it without changing the level of optimization? ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 18, 2020, 5:39am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/2 "2020-04-18T05:39:33Z")
Just as quick experiment, you may try increasing the stack size for your task. Use for example configMINIMAL\_STACK\_SIZE \* 2 in your call to xTaskCreate(). How is configCHECK\_FOR\_STACK\_OVERFLOW defined in FreeRTOSConfig.h? ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 5:53am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/3 "2020-04-18T05:53:46Z")
There is hardly a problem in the stack overflow - `vApplicationStackOverflowHook()` is not called, and besides, I tried to increase the size of the stack earlier. `configCHECK_FOR_STACK_OVERFLOW` is set to 2. ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 18, 2020, 6:53am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/4 "2020-04-18T06:53:04Z")
Just checking some basic things. Does your linker file provide some heap space and main stack too? And for clarification, you’re saying you get hard fault in vTaskDelay, unless you step through it in the debugger? ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 7:02am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/5 "2020-04-18T07:02:31Z")
Linker file contents: [https://pastebin.com/pvibDCMN](https://pastebin.com/pvibDCMN) Yes, if go through all the stages (macros, function calls) sequentially in the debugger, then everything works (maybe this is a cumulative error). However, during normal startup, Hard Fault occurs. ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 18, 2020, 7:21am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/6 "2020-04-18T07:21:17Z")
Is configUSE\_MALLOC\_FAILED\_HOOK defined? I can’t make a lot of sense out of what you’re seeing. Did you start this project with a FreeRTOS example project? Which one? ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 7:27am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/7 "2020-04-18T07:27:46Z")
configUSE\_MALLOC\_FAILED\_HOOK is set to 0. Not certainly in that way. I used the libopencm3 template, in which I configured the Makefile and added FreeRTOS (source and header files, as well as the configuration file). ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 18, 2020, 7:32am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/8 "2020-04-18T07:32:44Z")
Set configUSE\_MALLOC\_FAILED\_HOOK to 1, and add the corresponding handler vApplicationMallocFailedHook(). If nothing else (and if nobody else on the forum has any better ideas) you may need to start with an example project from FreeRTOS or at least carefully review one as a reference. ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 7:45am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/9 "2020-04-18T07:45:46Z")
Declared a function, but this did not help - the program does not get there. Is there any debugger capable of tracing assembler code (like x64dbg for Windows, for example)? ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 7:49am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/10 "2020-04-18T07:49:53Z")
And one more thing - can this be due to the FPU? When creating the project, I selected a file for the M4F core, but perhaps for it to work correctly it needs to be configured somehow (the microcontroller contains this block)? ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 18, 2020, 2:43pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/11 "2020-04-18T14:43:08Z")
> [@Marionette](#): > > Is there any debugger capable of tracing assembler code (like x64dbg for Windows, for example)? Getting a trace buffer on STM32 requires an upgraded debugger (like J-Trace). > [@Marionette](#): > > And one more thing - can this be due to the FPU? Possibly. Are you using the FreeRTOS port for Cortex M4? And is your STM32 a Cortex M4? You definitely have to use the port that matches your MCU. Which STM32 is it? I don’t know anything about libopencm3, and it may need some configuration too. There are so many things that could go wrong, that’s why both ST and FreeRTOS provide working example projects. I use CubeIDE from ST (though I don’t use the code generator), newlib, and J-Link, and for what it’s worth they work fine, especially for the price. 😀 ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 18, 2020, 3:58pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/12 "2020-04-18T15:58:51Z")
I am using `STM32F407VGT6` (`STM32F4-DISC1`). Took the file for the `GCC` compiler for the `M4F` architecture. ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 18, 2020, 5:49pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/13 "2020-04-18T17:49:06Z")
I’m not sure I can help. There are compiler and linker settings, runtime library configuration questions, and you are not starting from a known-working demo project. If I were you I would switch to CubeIDE and start with a demo project. Then slowly replace their pieces with your pieces until you find out what breaks the project. If you don’t do that, I think the best lead you have going for you is that the code works when you step through it in the debugger. Explore the space between single-stepping through the code and not using the debugger at all. (Lots of space in between those two extremes by placing breakpoints strategically.) You’ll need to understand how FreeRTOS works in order to do that, but that knowledge is worthwhile anyway. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [April 18, 2020, 6:53pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/14 "2020-04-18T18:53:15Z")
First check the LED on and off functions execute as you expect by simply having a sequence of on, off, on, off in main() before you do anything else, then step over each call to turn the LED on and off in the debugger. Which [heap implementation](https://www.freertos.org/a00111.html) are you using? FreeRTOS requires a couple of interrupt handlers - SVC and PendSV. If you enter the first task ok then the required SVC handler must be installed ok, as SVC is used to start the first task. If the first task runs, but vTaskDelay() crashes, then it is possible you don’t have the correct PendSV handler installed. You said when you replace the call to vTaskDelay() with a null loop (one that doesn’t switch away from the task) it runs ok - when you do that does the tick interrupt execute? The simplest way to tell is to break in the debugger then inspect the value of xTickCount in tasks.c - if the tick interrupt is not executing it could mean PendSV is not installed. ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 20, 2020, 10:06am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/15 "2020-04-20T10:06:44Z")
I made several toggles in `main()` - everything is in order (it also works with cycle). I’m using the fourth implementation of the heap. All handlers are installed and operational (first SVC, then twice PendSV, - on the last call Hard Fault occurs; When `pend_sv_handler` is called a second time, the `xTickCount` value is increased from 0 to 1000): ![Untitle](https://d2v6vdsk2p900z.cloudfront.net/original/1X/15e064b1ea98529df0d846d5fed3c4ec9568fd5e.png) ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 20, 2020, 5:21pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/16 "2020-04-20T17:21:29Z")
Can you post the disassembly for pend\_sv\_handler(), with and without optimization? Curious about main stack (mis-)use. ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 20, 2020, 6:22pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/17 "2020-04-20T18:22:25Z")
This is amazing, but the functions turned out to be exactly the same, with the exception of the addresses, of course ([https://pastebin.com/mB5RvM93](https://pastebin.com/mB5RvM93) [https://pastebin.com/h0jVYEUX](https://pastebin.com/h0jVYEUX)). By the way, I noticed a check for stack overflow (macro) in the context switching task. I decided to look there to find out exactly how the check for stack overflow occurs (in the context of the IDLE task, of course). I got a pointer to the stack, after manually checking each value - and it only became more incomprehensible. The first coincided, but the other three have the last byte different. But why is the overflow handler not called? How can 128 bytes not be enough in such a simple task? Although, perhaps, I was mistaken in some ways during the research, because even before entering vLedToggle the values ​​do not match. Among other things. The task flow, after switching contexts and returning to vTaskDelay, falls into xTaskResumeAll, where it supposedly gets stuck on the taskEXIT\_CRITICAL macro, although in fact the mysterious address 0xa5a5a5a4 is again located at top on the stack (I didn’t see this on the stack when I performed a manual check). And the pc register, respectively, is equal to this address. If release the program, it falls into the Hard Fault handler, otherwise it simply will not exit this section. ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 20, 2020, 7:54pm UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/18 "2020-04-20T19:54:59Z")
> [@Marionette](#): > > How can 128 bytes be enough in such a simple task? It’s 128 32-bit _words_, and it’s the _minimum_ stack required for any task. Sounds like the stack pattern you are checking is not the overflow fence but the pattern for finding the high-water mark (perhaps you have INCLUDE\_uxTaskGetStackHighWaterMark set to 1). The disassembly you posted isn’t for pend\_sv\_handler(). It’s for xPortPendSVHandler(), which of course doesn’t change with optimization because it’s a naked pure-asm function. Can you post the disassembly for pend\_sv\_handler() – with and without optimization. If it stacks the LR (or anything else) before calling xPortPendSVHandler(), that’s a bad thing. That function doesn’t return. Function xPortPendSVHandler() is intended to _be_ the ISR not be called by the ISR. ---
**Author:** ![Marionette](https://avatars.discourse-cdn.com/v4/letter/m/bc79bd/32.png) [@Marionette](https://forums.freertos.org/u/Marionette)\ **Post date:** [April 21, 2020, 4:35am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/19 "2020-04-21T04:35:54Z")
> [@jefftenney](#): > > It’s 128 32-bit _words_ So, as many as 512 bytes are allocated per task? > [@jefftenney](#): > > but the pattern for finding the high-water mark What does it mean? INCLUDE\_uxTaskGetStackHighWaterMark is disabled. > [@jefftenney](#): > > which of course doesn’t change with optimization because it’s a naked pure-asm function Does it not change because it is written in assembler or because it is declared naked? > [@jefftenney](#): > > Function xPortPendSVHandler() is intended to _be_ the ISR not be called by the ISR. Do you mean that xPortPendSVHandler should be immediately in the interrupt table, and not called manually? Without optimization: ```auto 08000290 : 8000290: b580 push {r7, lr} 8000292: af00 add r7, sp, #0 8000294: f000 fbe4 bl 8000a60 8000298: bf00 nop 800029a: bd80 pop {r7, pc} ``` With: ```auto 0800024c : 800024c: b508 push {r3, lr} 800024e: f000 fa07 bl 8000660 8000252: bd08 pop {r3, pc} ``` ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [April 21, 2020, 4:56am UTC](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562/20 "2020-04-21T04:56:30Z")
> [@Marionette](#): > > So, as many as 512 bytes are allocated per task? A minimum of 512 bytes are allocated per task, yes. > [@Marionette](#): > > What does it mean? INCLUDE\_uxTaskGetStackHighWaterMark is disabled. When configCHECK\_FOR\_STACK\_OVERFLOW is 2, or when INCLUDE\_uxTaskGetStackHighWaterMark is 1, a task’s stack area is filled with a pattern before the task starts. This pattern helps FreeRTOS detects a “high-water” mark, or the maximum amount of stack the task actually uses. In the case of configCHECK\_FOR\_STACK\_OVERFLOW, the pattern also helps the FreeRTOS notice that the task used too much stack. > [@Marionette](#): > > Does it not change because it is written in assembler or because it is declared naked? The compiler doesn’t try to optimize code inside \_\_asm statements. Naked functions contain only \_\_asm statements, so that code doesn’t change with/without optimization. > [@Marionette](#): > > Do you mean that xPortPendSVHandler should be immediately in the interrupt table, and not called manually? Yes, exactly. The disassembly you posted shows the problem. Each time pend\_sv\_handler() executes, it pushes two registers onto the main stack. However, because xPortPendsSVHandler() never returns, they never get cleaned up. The main stack continues to grow until it overflows and corrupts something important perhaps in the heap or elsewhere. Installing xPortPendSVHandler directly in the vector table will solve the problem. FreeRTOS does this typically with #define, but you can probably edit the vector table directly if you want. Be sure to install vPortSVCHandler() the same way. xPortSysTickHandler() doesn’t have the same requirement. One last mystery though. Why is your app running the PendSV handler so much? Do you have preemption turned off (configUSE\_PREEMPTION)? [Next page](https://forums.freertos.org/t/strange-behavior-of-vtaskdelay-when-optimization-is-turned-off-o0/9562.md?page=2)