Use of uxTaskGetStackHighWaterMark() vs configCHECK_FOR_STACK_OVERFLOW as 2

Kernel
1

Processor: STM32F405
FreeRtos: 10.5.1
If I set configCHECK_FOR_STACK_OVERFLOW to 2 then it places special values on 16 bytes of the task stack and I believe then checks them and if corrupted calls vApplicationStackOverflowHook() This I have working and is a great ability.

I have made a custom check based on usage of uxTaskGetStackHighWaterMark() which returns WORDS for high water. This works well which works and am wondering about the following:

  1. is uxTaskGetStackHighWaterMark() a very low overhead call based on task stack pointer registers or does is use similar stack special values used by configCHECK_FOR_STACK_OVERFLOW where the code walks through and checks all words?

  2. I am thinking of usage of configCHECK_FOR_STACK_OVERFLOW set to 1 combined with custom code to check for some high water threshold I choose and this custom routine uses uxTaskGetStackHighWaterMark() . Is this a lower runtime hit vs configCHECK_FOR_STACK_OVERFLOW set to 2 due to use of task stack pointer registers

  3. If it really is best to use configCHECK_FOR_STACK_OVERFLOW set to 2 then is there a way to change the number of bytes with custom pattern to a larger number such as 32 or 64?

The core of my custom checker is as follows:

 UBaseType_t uxHighWaterMark;
        uxHighWaterMark = uxTaskGetStackHighWaterMark( NULL );
        while (uxHighWaterMark <= TASK_STACK_HIGH_WATER_MIN) {   // This can be 32
            static uint32_t g_procStackPointer;   // Show task SP for deeper debug if in debugger
            __asm volatile ( "mrs %0, psp" : "=r" ( g_procStackPointer ) );
            vTaskDelay(5);  // Keep this task here forever if we hit this limit
        }

Thank you for your thoughts.

2

It walks the stack from top and check for unaltered bytes - FreeRTOS-Kernel/tasks.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub.

configCHECK_FOR_STACK_OVERFLOW 2 checks last 4 words - FreeRTOS-Kernel/include/stack_macros.h at main · FreeRTOS/FreeRTOS-Kernel · GitHub.

configCHECK_FOR_STACK_OVERFLOW and uxTaskGetStackHighWaterMark are meant for different purposes -

  1. configCHECK_FOR_STACK_OVERFLOW is a debugging aid to catch stack overflow after it has happened.
  2. uxTaskGetStackHighWaterMark, on the other hand, is provided to help the application writer to tune the task stack size.

What do you want to achieve?