Using Timer Global Interrupt crashes board

Pepijn · ‎2024-01-19

I have an Arduino Giga (STM32H7). I'm trying to generate an interrupt on the Catch/Compare even of TIM5_CH3. TIM5 is set to one pulse mode and triggered as a slave to TIM1, they generate some PWMs; everything is working absolutely fine there. Also, I've successfully used the CC interrupt of TIM1, and now I'm trying to do the same for TIM5, which only has a global interrupt handler. I've reduced my program to its simplest form for demonstration purposes:

TIM5->DIER = 0; //disable all interrups on TIM5
TIM5->SR = 0;   //set all flags down
TIM5->DIER |= TIM_DIER_CC3IE;    //enable interrupt from CH3

NVIC_EnableIRQ(TIM5_IRQn); //enable TIM5 ISR
	
// I don't set the priority here, doesn't seem to matter


extern "C" void TIM5_IRQHandler(void){
  TIM5->SR = 0; //set all flags to 0 again
}

For some reason, this makes the board unresponsive. I feel like I'm missing something obvious, even though this feels very safe. Only CH3 can generate an interrupt, which it does successfully (since it only crashes when the DIER_CC3IE is set). Then I just set its flag to 0 again (and all others, just for the sake of it).

Any help would be greatly appreciated!

jimAtTSG · ‎2024-05-02

Thanks. Yes there are other timers, but this 32-bit timer would make it easier to insure we didn't miss any ticks when counting from a hi-res hardware encoder.

There is a reference to TIM5 in us_ticker_data.h, but I don't know enough to know if or when that file is used. Maybe it isn't used or maybe it is used in a rebuild of mbed.

What we found is that if we didn't reprogram TIM5 it appeared the TIM5-CNT was a us counter. If we did reprogram it and did not rotate the encoder, we did not observe any crashes. Same thin for rotating the encoder in a direction the incremented TIM5->CNT. But if we rotated the encoder in the other direction to decrement TIM5->CNT, our Ethernet communications would crash. So far the only way to recover from that was to reboot. It looked to me like the backwards counting somehow caused Ethernet.linkstatus to report that the link was no longer on.

Pepijn · ‎2024-05-02

Just a final point, you could also just use TIM2, it's identical to TIM5 in functionality, if you want to eliminate the possibility of TIM5 not acting right for whatever reason.