Watchdog Feeding Issues with FreeRTOS

Kernel
1

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

2

This is a curious one, if you are sure the task is executing and that it is executing at the expected frequency, and you are sure the source code that feeds the dog is correct, then it doesn’t leave much else. Is IWDG->KR = 0xAAAA; the only instruction required to feed the dog? Is there anything different about the address of IWDG or the processors ability to access that address before and after the scheduler? For example, if the memory protection unit were turned on then it might be that the task can no longer access the watchdog.

1 Like
3

How is the watchdog task re-triggered or what else is done in your watchdog task ? Do you use e.g. a simple vTaskDelay to give up the CPU for a while ?
IWDG works fine for me. I don’t use the window feature, but that shouldn’t really matter.
__disable_irq();__enable_irq() is not needed.

1 Like
4

I checked with the STM32H7 hardware and it works for me. Following is the code I used for refreshing the watchdog:

void StartDefaultTask(void *argument)
{
  for(;;)
  {
	HAL_IWDG_Refresh(&(hiwdg1));
    osDelay(10);
  } 
}

The code generated by CubeMX to initialize IWDG is this:

static void MX_IWDG1_Init(void)
{

  /* USER CODE BEGIN IWDG1_Init 0 */

  /* USER CODE END IWDG1_Init 0 */

  /* USER CODE BEGIN IWDG1_Init 1 */

  /* USER CODE END IWDG1_Init 1 */
  hiwdg1.Instance = IWDG1;
  hiwdg1.Init.Prescaler = IWDG_PRESCALER_4;
  hiwdg1.Init.Window = 4095;
  hiwdg1.Init.Reload = 4095;
  if (HAL_IWDG_Init(&hiwdg1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN IWDG1_Init 2 */

  /* USER CODE END IWDG1_Init 2 */

}

Are you doing something different? Can you share your code snippet?

Thanks.

1 Like
5

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.

6

Well, I’m using watchdog timeouts of a couple of seconds because I’m using it as last resort on fatal errors. 512 ms is pretty tight e.g. when doing flash erase/programming in your application which might take N x 100 ms and stalls execution from (single banked) flash regardless of any priority scheme. If you can you could relax your timeout a bit to avoid false watchdog events.