Skip to main content
sonic1015
sonic1015
Associate
April 3, 2023
Solved

IWDG not stopping on debug when CAN Receive interrupt triggered

  • April 3, 2023
  • 2 replies
  • 1427 views

I'm having a significant problem debugging my board with CAN traffic. Whenever the debugger is paused, and a CAN message is received via interrupt, the independent watchdog is being reset. As far as I can tell, I'm disabling that peripheral on debug correctly, but anytime I set a breakpoint, the IWDG is resetting the MCU. If my board does NOT receive any CAN messages, everything works as expected.

Relevant Information

  • MCU: STM32F091VB
  • Development Environment: IAR Embedded Workbench 9.30
  • Debug Probe: STLink/V2

Below is my code for disabling peripherals for debugging:

//Halt Interrupts on Debug stop
__HAL_RCC_DBGMCU_CLK_ENABLE();
__HAL_FREEZE_IWDG_DBGMCU();
__HAL_FREEZE_WWDG_DBGMCU();
__HAL_FREEZE_TIM1_DBGMCU();
__HAL_FREEZE_TIM2_DBGMCU();
__HAL_FREEZE_TIM3_DBGMCU();
__HAL_FREEZE_TIM16_DBGMCU();
__HAL_FREEZE_CAN_DBGMCU();

Disabling the watchdog entirely appeared to work, but pausing in the debugger only allows me to debug the CAN interrupt, so it seems when the debugger is paused, the MCU gets stuck in the CAN interrupt.

This topic has been closed for replies.
Best answer by sonic1015

So, I actually did manage to solve the problem.

I was reorganizing my code, and choosing a different implementation for initializing CAN hardware. The new implementation removed these three lines:

RCC->APB1RSTR &= ~RCC_APB1RSTR_CANRST;
RCC->APB1ENR |= RCC_APB1ENR_CANEN;
CAN->MCR = 0x00008000;

After that, I was able to debug as normal. Not exactly sure which line is the culprit but... problem solved...

2 replies

S
Sarra.S
ST Employee
May 5, 2023

Hello @sonic1015​, and welcome to ST Community,

As far as you explained, I think it's a timing issue

>> The MCU gets stuck in the CAN interrupt

I also think that when the debugger is paused, the CAN message interrupts the MCU, which causes the watchdog to reset since the interrupt takes too long to process...

You can try to increase the CAN interrupt priority so that it will be processed first and the watchdog won't reset the MCU!

I hope that helps!

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
sonic1015
sonic1015AuthorBest answer
Associate
May 5, 2023

So, I actually did manage to solve the problem.

I was reorganizing my code, and choosing a different implementation for initializing CAN hardware. The new implementation removed these three lines:

RCC->APB1RSTR &= ~RCC_APB1RSTR_CANRST;
RCC->APB1ENR |= RCC_APB1ENR_CANEN;
CAN->MCR = 0x00008000;

After that, I was able to debug as normal. Not exactly sure which line is the culprit but... problem solved...

Terms & ConditionsAccessibility statement