Odd Issue With STM32L071CB When Initialising Watchdog

[MClarke]

I'm having an issue with initialising my watchdog, when I include the call to HAL_WWDG_INIT(&hwwdg2) in my code, it is causing any debug attempt to run into the hardfault handler due to some values in SystemClock_Config() being set to 0:

__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
/* Configure the SysTick to have interrupt in 1ms time basis*/
if (HAL_SYSTICK_Config(SystemCoreClock / (1000U / uwTickFreq)) > 0U)
{
return HAL_ERROR;
}

...

The SystemCoreClock and uwTickFreq values both get set to 0 when the execution reaches them. If I comment out my HAL_WWDG_INIT call, the execution will work without issue. The HAL_WWDG_INIT isn't even being ran before whatever is happening happens, if I put a breakpoint on both there and in the HAL_InitTick function, the HAL_InitTick function is reached first with the values altered.

Here's my Watchdog initialisation, it seems fairly innocuous:

static void MX_WWDG_Init(void)

{

hwwdg2.Instance = WWDG;

hwwdg2.Init.Prescaler = WWDG_PRESCALER_1;

hwwdg2.Init.Window = 64;

hwwdg2.Init.Counter = 64;

hwwdg2.Init.EWIMode = WWDG_EWI_DISABLE;

if (HAL_WWDG_Init(&hwwdg2) != HAL_OK)

{

Error_Handler();

}

/* USER CODE BEGIN WWDG_Init 0 */

/* USER CODE END WWDG_Init 0 */

/* USER CODE BEGIN WWDG_Init 1 */

/* USER CODE END WWDG_Init 1 */

/* USER CODE BEGIN WWDG_Init 2 */

/* USER CODE END WWDG_Init 2 */

}

If anyone has any insight or advice, I would be grateful to receive any!

[TDK]

SystemCoreClock should never be 0. It should be initialized in system_stm32*.c and updated in SystemCoreClockUpdate. Ensure those are happening.

Similarly, uwTickFreq should never be 0.

You can set a hardware watchpoint on these values and the debugger will break when they are modified. Perhaps you have a buffer overrun somewhere or other out of bounds write which is setting them to 0.

[MClarke]

I agree, that's what I find so unusual about this issue. It seems contingent on whether I have HAL_WWDG_Init in my code, not that it is even being ran. 

[TDK]

Which isn't logical, right? So set a watchpoint and find out what is changing it. Or step through code to figure out where/why it's changed.

[MClarke]

As a follow up to this topic, I've observed similar behaviour when trying to add completely innocuous code to my STM32 project. I don't think the watchdog is/was the issue.

I think this is some sort of strange memory issue, as this is a project I have (incorrectly?) reconfigured to use a STM chip with a larger FLASH size (originally using STM32L071C8), maybe the project is somehow "wrapping over" memory addresses it thinks are beyond my initial FLASH limitation by overwriting lower addresses of FLASH.

I've transferred my code to a new project with the target chip, and I haven't seen the issue again.