L431 debug stops after enabling timer update interrupt

[ZJing]

Hi all,

I have encountered a problem where the debug would stop working as soon as the program hits the line where TIM15's update interrupt is enabled. From there the program appears to be still running but would not stop at any breakpoints and live expressions would show zeros and blanks as well.

The line(s) after which debug would stop working:

LL_TIM_EnableIT_UPDATE(TIM15);			//Debug stops working after this line
LL_TIM_EnableCounter(TIM15);

TIM15 is set to have a period of around 7.2kHz, with initialization code as below:

	LL_TIM_Init(TIM15, &PHtimer);
	//LL_TIM_DisableARRPreload(TIM15);
	LL_TIM_SetOnePulseMode(TIM15, LL_TIM_ONEPULSEMODE_REPETITIVE);
	LL_TIM_SetUpdateSource(TIM15, LL_TIM_UPDATESOURCE_COUNTER);
	NVIC_EnableIRQ(TIM1_BRK_TIM15_IRQn);

Please let me know of your insights on why this problem would occur, thank you!

Zhi

[Pavel A.]

Interesting. If you put a breakpoint on the TIM15  interrupt handler, will it break there?

[waclawek.jan]

And then the next logical question is, what exactly is in the TIM15 ISR?

JW

[Pavel A.]

Given the source snippet above with NVIC_EnableIRQ it should be TIM1_BRK_TIM15_IRQHandler

[ZJing]

Hi Pavel, no it will not reach that breakpoint. In fact I have added a breakpoint after these 2 lines: 

LL_TIM_EnableIT_UPDATE(TIM15);			//Debug stops working after this line
LL_TIM_EnableCounter(TIM15);

and it would not even break there

[ZJing]

Hello JW,

Below is the TIM15 ISR:

void TIM1_BRK_TIM15_IRQHandler(void)
{
	if(LL_TIM_IsActiveFlag_UPDATE(TIM15))
	{
		LL_TIM_ClearFlag_UPDATE(TIM15);
		LL_GPIO_TogglePin(PH_PORT, PH_PIN);
	}
}

[ZJing]

Yes, this is it 

[waclawek.jan]

In debugger, check SBC_VTOR value and at the address where it points to, check, if the (in particular, if VTOR=0, check, if you don't have the System memory mapped at address 0 as consequence of bootloader getting inadvertently activated).

In disassembler view, check if the ISR's  address is properly inserted into the vector table.

JW

[ZJing · Accepted solution]

Hi all,

It turns out that high frequency interrupts has caused this problem either alone or in combination with other factors. After changing it to DMA the problem is gone.