STR912 wierd interrupt handling

[istvan]

Posted on July 24, 2012 at 09:46

Dear Colleagues,

I have a common interrupt handling issue with a Keil MCBSTR9 eval kit.

Everything works fine, but it's just not handling an ISR properly. I'm using vendor given ISR routines, for example

void TIM3_IRQHandler(void){ /*write your handler here*/ /* ... */ //blablabla my ISR...// TIM_ClearFlag(TIM3, TIM_FLAG_OC2); /*write any value to VIC0 VAR*/ VIC0->VAR = 0xFF;}

This works fine, but won't return from the ISR after executing it. 

So at the end I stated to the compiler the

__irq

directive infont of the ISR function, but then the compiler says that the definition of

__irq 

void TIM3_IRQHandler(void)in 91x_it.h isn't correct. So I changed it in 91x_it.h and now it works well.But at the end of the line I don't think that it's common or safe to change the vendor given libraries, so I must be missing here something. Any ideas about this?I am certaing that without the _irq directive the compiler (with my setup) can't tell that 91x_it.c contains ISR routines, and that's the reason that my ISR's aren't handled as such, but I can't tell what am I missing....

#irq-handling-str91x

[istvan]

Posted on July 24, 2012 at 09:49

Sorry about the bad paste of code, yet it's just a simple vendor given ISR code in 91x_it.c where I am inserting my own service of the irq

[Pantuca.Erwin]

Posted on July 27, 2012 at 06:09

i have seen some examples for different compilers (for str912), it is not required for most of them.  the timer function itself is not the entry/exit point of the isr, it is ''IRQHandler'' in 91x_vect.s, which branches to the corresponding handler set from 91x_vic.c. i suggest you trace the assembler from your debugger how it is compiled differently. it is possible, your directive just pre-empts the normal isr return from IRQHandler (which follows right after your function exits) that is why it works.  there might be something else that needs to be set in your environment or configuration.

[istvan]

Posted on January 03, 2013 at 19:10

Thanks for the answer,

Believe or not, I'm still stuck on this.

I program other microcontrollers for over 10 years (like MSP430), this shouldn't be happening. Now I utilised my Keil programmer and the ARM board and I am determined to solve this once for all.

My problem is that my routine either doesn't know how to leave the ISR (then i get and undef nmi) or if I put the __irq instruction infront of the ISR function, it gets stuck in the ISR endlessly.

I can't believe that I'm the only one with this problem....

[istvan]

Posted on January 03, 2013 at 21:21

like you suggested, I pit a breakpoint to the interrupt handling routine. It never even jumps to it. It's getting stuck in the Undefined Handler. Hm....

Is there something wrong with my interrupr setup routine?

 TIM_ITConfig(TIM3, TIM_IT_OC2, ENABLE);

 TIM_CounterCmd(TIM3, TIM_CLEAR);

 TIM_CounterCmd(TIM3, TIM_START);

 VIC_ITCmd(TIM3_ITLine, ENABLE);

 VIC_Config(TIM3_ITLine, VIC_IRQ,7);

[Pantuca.Erwin]

Posted on January 04, 2013 at 09:48

we ourselves have had various interrupt issues.  the most major caused by an errata.  i suggest read the latest errata for str9. it took months before we found the solution in AN2593.

i also suggest for better understanding of interrupts to understand this document how str9 handles interrupts.

[istvan]

Posted on January 05, 2013 at 20:54

My problem seems to be that I can't handle any interrupt.

I've read all the documents of IRQ handling in STR912, and it's not any different than most other microcontrollers, but the examples are very confusing.

The only truly working example is the Blinky but it's not using the STR91x library.

In my project setup I include all the .s files (including IRQ.s), and it's very clear how it handles the IRQ, and the interrupt handlers are ready given in 91x_it.c so I use them, and it should be as easy as that.

BUT, I tried to put a breakpoint in the IRQ.s - when an interrupt occurs my program never goes into that subroutine. I think about there is the core of my problem - the IRQ is not handled properly. Somehow, the program still ends up on my ISR routine, but after executing it once, it ends up in and endless Undef loop (when executing it on the simulator, it says Access violation at memory xxxx - no write permission - I think this is due that it doesn't know how to return from the ISR when it ends)....

I'm not sure where to go from here. I must be missing some tiny little thing that messes up all the ISR handling and all this time I can't figure out what.

Is it permited that I use the Keil configuration wizard (set up the memory, clocks, clock gating, etc etc), and then to use the 91x_lib.c routines to set up the timer, etc?

In the examples given by STM, they don't use the setup wizard in the project, they use only the 91x_lib.c routine to set up the whole processor...but I found it easier to click out what I need in the processor and how I need it (and that part is working) but to call the SCU functions 10-15times....

[Pantuca.Erwin]

Posted on January 11, 2013 at 06:00

would you check this message i posted here previously:

i have seen some examples for different compilers (for str912), it is not required for most of them.  the timer function itself is not the entry/exit point of the isr, it is ''IRQHandler'' in 91x_vect.s, which branches to the corresponding handler set from 91x_vic.c. i suggest you trace the assembler from your debugger how it is compiled differently. it is possible, your directive just pre-empts the normal isr return from IRQHandler (which follows right after your function exits) that is why it works.  there might be something else that needs to be set in your environment or configuration.

how is your IRQHandler written?

[istvan]

Posted on January 20, 2013 at 18:20

So far it's working.

It started working when I made explicit include patch to ../ and to the FW libraries downloaded from here.

Without it, it compiled but it seems that the compiler rather used some libraries that came with the Keil package, and it made a total mess of it.