Skip to main content
James Murray
James Murray
Associate III
March 10, 2021
Question

STM32F7 WWDG usable with HAL busy waits and long timeouts?

  • March 10, 2021
  • 4 replies
  • 1470 views

I have a C project on an STM32F745 that uses various HAL libraries.

Today I have enabled the WWDG (Windowed Watchdog.) I set the registers directly as I find that easier to understand and did this right at the start of main() to offer best protection against a lockup.

However, my application is resetting early on, sometimes before I have enabled interrupts, so it doesn't reach my crash reporter from the watchdog EWI handler. By adding status codes I have tracked the problem down to a timeout in the HAL code (HAL_RTC_Init)

I then remembered that there are large numbers of long timeouts or busy waits in HAL. e.g. there was a 5 second delay in the ethernet initialisation code.

The RTC code has a 1 second timeout. The WWDG has a maximum timeout in milliseconds.

How is HAL supposed to work with WWDG? Am I missing something, or is it just incompatible and I'll need to rewrite it? I already re-wrote the ETH_Init as the busy waits were unacceptable for my application.

James

This topic has been closed for replies.

4 replies

waclawek.jan
waclawek.jan
Super User
March 10, 2021

Well, I personally wouldn't touch Cube with a stick, but it appears that most Cube/HAL wait loops use HAL_GetTick(), so maybe a relatively quick remedy might be to intercept/rewrite HAL_GetTick() to refresh the watchdog.

Whether this decreases the value of watchdog or not, is upon you to decide.

JW

James Murray
James MurrayAuthor
Associate III
March 12, 2021

You wrote " I personally wouldn't touch Cube with a stick"

Out of interest, what alternative approach are you using?

James

waclawek.jan
waclawek.jan
Super User
March 12, 2021

Direct register access using symbols from the CMSIS-mandated device header.

JW

James Murray
James MurrayAuthor
Associate III
March 10, 2021

Thanks for responding.

After rewriting the RTC code, I had a WWDG reset in the SDMMC init code - more busy waits.

The HAL_LL_SDMMC code is using a different timeout mechanism with one of the default timeouts at 63 SECONDS ?!

I rewrote that code slightly to use the short busy wait and then a variant of your idea beyond the short timeout.

One possible overall "fix" for the libraries would be a call in HAL_GetTick to a "weak" function to reset the watchdog and apply this same call everywhere else there are busy waits.

It certainly does make me wonder about the suitability of the ST provided code. Busy waits in embedded work seems they hired the Windows programmer by mistake?

James

Terms & ConditionsAccessibility statement