1

I'm having a significant problem debugging my board with CAN traffic. Whenever the debugger is paused, and a CAN message is received, 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 i.e. I'm stuck infinitely in that interrupt, even if there are no CAN messages being received.

Edit

Here are the CAN registers, just before the Receive Mailbox Interrupt is cleared:

Screenshot of CAN registers

In addition, here is the DBGMU Register

Screenshot of Debug Registers

Lundin
  • 195,001
  • 40
  • 254
  • 396
sonic1015
  • 31
  • 4
  • 1
    Maybe you should show us the ISR for the CAN peripheral. Are you sure you clear the interrupt when you receive one? – pmacfarlane Apr 04 '23 at 17:52
  • Probably IAR is overwriting it, programming the DBGMCU freeze register when breakpoint is hit – 0___________ Apr 04 '23 at 18:17
  • 1
    _Side note:_ In addition to debug with a debugger, you may want an "event trace" buffer that can record events in realtime, similar to a logic analyzer. See my answer: [Need test to determine if asynchronous I/O is actually happening in C code](https://stackoverflow.com/a/65099395/5382650) Stopping a realtime program for a breakpoint can mask timing issues if the program can't be run at full speed. – Craig Estey Apr 04 '23 at 19:21
  • I've updated the post with the requests. I like the idea of an event logger/trace, and may look into that in the future. For now, being able to pause and step through code to watch the data changes, and look at variables is all I need at the moment. – sonic1015 Apr 04 '23 at 19:52
  • On various older debuggers you'd have to place a breakpoint somewhere in the main loop, then manually disable maskable interrupts in some "condition code register" (or equivalent). Been a while since I used a debugger like that but it's also been a long while since I last used IAR. There's probably some debugger setting you are missing - I added the IAR tag to the question. – Lundin Apr 05 '23 at 10:24
  • I've attempted to debug with an ST Link/V3, but got the same results. Is there a "newer" debugger, or could this be a Cortex-M0 chip lacking a feature of some sort? – sonic1015 Apr 05 '23 at 19:12

1 Answers1

0

Found the answer. I was reorganizing my code, and choosing a different implementation for initializing CAN hardware. 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 suffice to say HAL libraries for the win.

sonic1015
  • 31
  • 4