This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interrupt question

Hi,

I'm using the STM32F103ZD.

The TIM2_IRQHandler() interrupt handler decrements a value, checks for zero, if so does some action and (re-) sets this value to 1. So each call to this interrupt handler should execute some action.
Also higher priority interrupts are active.

If the program execution fails I see in the debugger that 'value' has decremented through zero to 0xffff and lower. Is this some atomic problem? Or is the interrupt handler somehow re-entered while executing?


// variabele declaration
volatile static unsigned short value=1;

// timer 2 interrupt handler
void TIM2_IRQHandler(void){
  // an update event is detected
  if(TIM2->SR&TIM_SR_UIF){
    // clear the update event interrupt flag
    TIM2->SR&=~TIM_SR_UIF;
    // decrement some value
    value--;
    // value is zero
    if (!value){
      // do something
      DoSomething();
      // preset value
      value=1;
    }//if
  }//if
}//TIM2_IRQHandler

Who can help me out?
Thanks
Henk

Parents
  • Per,

    What you have explained there covers what I consider to be an incredibly frequent error.

    One such situation occurred for me just a few months ago I was involved in looking at outstanding problems in some (rather nasty) source code.

    I came across this very fault in a low level driver and had a difficult time getting through to some people who claimed to be seasoned firmware engineers that they were doing it wrong.

    Their argument: the compiler is supposed to look after situations like that.

    After persuading them to try changing the code, the problem was no longer witnessed.

    Most (but not all) of the team then took the situation on board.

Reply
  • Per,

    What you have explained there covers what I consider to be an incredibly frequent error.

    One such situation occurred for me just a few months ago I was involved in looking at outstanding problems in some (rather nasty) source code.

    I came across this very fault in a low level driver and had a difficult time getting through to some people who claimed to be seasoned firmware engineers that they were doing it wrong.

    Their argument: the compiler is supposed to look after situations like that.

    After persuading them to try changing the code, the problem was no longer witnessed.

    Most (but not all) of the team then took the situation on board.

Children
No data