cancel
Showing results for 
Search instead for 
Did you mean: 

L431 debug stops after enabling timer update interrupt

ZJing
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions
ZJing
Associate III

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.

View solution in original post

8 REPLIES 8
Pavel A.
Evangelist II

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

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

JW

Pavel A.
Evangelist II

Given the source snippet above with NVIC_EnableIRQ it should be TIM1_BRK_TIM15_IRQHandler

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

 

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);
	}
}

 

 

Yes, this is it 

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
Associate III

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.