How can I get the Timer status register (SR) in an interrupt routine or why it is not working?

[CPete.2]

Hi, i am very new to microcontrollers and have a problem that I cannot understand.

I use a STM32F407 on a Discovery board. I set up channel 1 and channel 2 of the TIM2 timer for input capture. As soon the execution jumps into the interrupt handler "HAL_TIM_IC_CaptureCallback" (and stop on breakpoint at line 3) I can see the right values for SR in the debugger's SFRs window. So, the UIF-flag is set and CC1IF and/or CC1IF. If I do now one step further from the breakpoint, the CCxIF-flags get set to 0. The datasheet says that those got reset by query the CCRx-value but I don't do this:

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)
{
	uint8_t t_status = 0;
	
	if(TIM2->SR & TIM_SR_CC1IF)
		t_status = 1;
	else if (TIM2->SR & TIM_SR_CC2IF)
		t_status = 2;

Is it not possible to read the registers in an interrupt routine?

What is the right way to get the channel that caused the interrupt?

What could it be that i do wrong?

Also when it hits the breakpoint the first time in the interrupt routine the CCRx-value I query is not the same like in the debugger's SFRs window.

BR

Christian

[TDK]

> Is it not possible to read the registers in an interrupt routine?

Flags are cleared prior to the HAL callbacks being called. So you can read SR but it won't have the info you're looking for.

> What is the right way to get the channel that caused the interrupt?

The HAL way is to check htim->Channel value for HAL_TIM_ACTIVE_CHANNEL_1 or similar.

> Also when it hits the breakpoint the first time in the interrupt routine the CCRx-value I query is not the same like in the debugger's SFRs window.

Timers keep running when paused in debug mode which can cause register values to change. Probably a result of this.

[waclawek.jan]

HAL_TIM_IC_CaptureCallback() is *not* the ISR, TIM2_IRQHandler() and whatever is called from there is.

> What is the right way to get the channel that caused the interrupt?

The right way is to ditch Cube/HAL, although many consider this be opiniated.

TDK gave you the answer for this particular case, would you want to stick to Cube/HAL. Generally, you are supposed to read Cube/HAL's manual. You may find it lacking at times, you may then resort to reading Cube/HAL's sources - it's open source - and then of course read the RM too.

> Timers keep running when paused in debug mode

... unless you - or the debugger - makes them stop during debugging by setting the corresponding DBGMCU_APB1_FZ or DBGMCU_APB2_FZ bit.

Also note, that observing registers in debugger may be intrusive - here, specifically, reading TIMx_CCRx registers clear the respective TIMx_SR.CCxIF bit.

JW

[CPete.2]

Omg, I already had it like TDK described but obviously at that time I had another issue too. I now also remember that I already read that the flags get cleared prior to the HAL callbacks but at the beginning all the information are so overwhelming that I just can't remember on each detail (in this case a very very very important detail).

So in the end it is working and I have to say "Thanks a lot" to pointing me into the right direction.