Watchdog Feeding Issues with FreeRTOS

[Pain]

Hello All, 

Working with an STM32F4 processor and having issues with feeding the independent watchdog. Code is CubeMX generated. FreeRTOS v10.2.1 and CMSIS-RTOS V1.02. Watchdog resets if not fed every 512ms. Watchdog is fed in its own task and the priority is set to osPriorityRealTime. All the other tasks are osPriorityNormal. configTICK_RATE_HZ is set to a 1000 and configUSE_PREEMPTION is set to 1. The SYS timebase source was also changed from Systick to TIM7 as per a warning popup on CubeMX. 

So the issue I'm facing is that the watchdog resets the processor consistently every half a second or so even though I'm feeding it in the RealTime Task. I can confirm that it is the independent watchdog resetting the processor from the RCC->CSR register. I can also confirm that it is not an issue with the feeding process, as if I create an infinite loop right before the osKernalStart() and feed the dog in there the microcontroller runs perfectly fine and if I don't feed the dog in there it resets every half a second like it should. I've also included __disable_irq();__enable_irq(); during the feeding process and it does not help. Also the code stops at breakpoints set on the line feeding the dog and steps through fine. I've tried setting up variables that increment (x++) before and after the watchdog feed line, and just letting it run (till it resets) shows both the counters increment evenly, I couldn't quite get SystemView to work and also don't want to fork out $2.5k for Tracelyzer either so do let me know if there are any other alternate methods to debug FreeRTOS other than the traditional debug window and setting breakpoints like I'm doing right now. I've tried both IWDG->KR = 0xAAAA; and HAL_IWDG_Refresh(&hiwdg); both do not work with FreeRTOS but works fine otherwise. Any and all help appreciated. 

Thanks 

[KnarfB]

The highest prio task that is ready will always be scheduled (running), so: whats blocking the watchdog task? Maybe you can show some code. I wouldn't use an extra watchdog task but pet IWDG in either one of the existing periodic tasks or the idle task. This helps to detect overload situations too. What happens if you relax the timing? You can configure an IWDG interrupt shortly before "it happens" and debug at that point.

[TDK]

With IWDG disabled, flip a GPIO pin in the task instead and watch it in a logic analyzer or scope to see if it's actually being run and to see how frequently it runs. If it's never ran, there's your problem. If not, then it's likely a bug in your code. Unlikely to be a hardware problem.

[Pain · Accepted solution]

Sorry for not responding, I think I have found a solution. One of my tasks (osPriorityNormal) was exclusively dealing with STemWin functions and it seemed like that task every so often would cause the Watchdog task (osPriorityRealTime) to miss a cycle of execution and reset. Don't know why or how. I checked the stack size via the uxTaskGetStackHighWaterMark() and it was never utilizing more than 50% of the stack.  

I lowered the priority of the task dealing with STemWin to osPriorityBelowNormal, making it the lowest priority task as per the emWin documentation and that fixed the issue. Now the watchdog task runs perfectly and the watchdog is being strobed without any hiccups. This feels more like a hack than a legitimate solution. Feel free to reply. Thanks.