Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
|
My little program runs from ram, the board is in EVB mode (dbug12 in flash). It uses RTI interrupts, approx. as follows: volatile int foo = 0; rti_interrupt_handler() { foo = 100; } test_func() { enable_rti_interrupts(); while (foo == 0); // spin // continue } The interrupts happen, the handler runs, but the program never gets past the spin loop. The frequency divisor (RTICTL) is set to 10X2^16, and osc_clock is 4000000, so (if I'm understanding this stuff right) there should be an interrupt about every .16 seconds, i.e. pretty low frequency. My only guess is that dbug12 is adding some _huge_ overhead to interrupt handling, so that even though my handler is extremely short, by the time it finishes there's another interrupt pending. Anyone know is this is plausible? Is there some known problem with using interrupts in EVB mode? Patrick |
|
|
|
I used D-BUg to develop codes and no, D-BUG does not put huge overhead. I am not much good at C but where is 'foo' decremented. Is it automatically being decremented somewhere else? --- In , "ctrobot28" <pdm@o...> wrote: > My little program runs from ram, the board is in EVB mode (dbug12 in > flash). It uses RTI interrupts, approx. as follows: > > volatile int foo = 0; > > rti_interrupt_handler() { foo = 100; } > > test_func() { > enable_rti_interrupts(); > while (foo == 0); // spin > // continue > } > > The interrupts happen, the handler runs, but the program never gets > past the spin loop. The frequency divisor (RTICTL) is set to 10X2^16, > and osc_clock is 4000000, so (if I'm understanding this stuff right) > there should be an interrupt about every .16 seconds, i.e. pretty low > frequency. My only guess is that dbug12 is adding some _huge_ > overhead to interrupt handling, so that even though my handler is > extremely short, by the time it finishes there's another interrupt > pending. Anyone know is this is plausible? Is there some known > problem with using interrupts in EVB mode? > > Patrick |
|
|
|
I see where you are changing the value of 'foo' to get out of the loop, but I don't see in the interrupt handler where you clear RTIF. According to the book, you need to clear RTIF by writing to the real-time interrupt flag register (RTIFLG) with RTIF (bit 7) set. Otherwise you have a constant flag that triggers the interrupt; as soon as you leave the interrupt handler it is immediately called again because of the flag. Hope this helps. -- DW --- In , "zeta_alpha2002" <zeta_alpha2002@y...> wrote: > I used D-BUg to develop codes and no, D-BUG does not put huge > overhead. > > I am not much good at C but where is 'foo' decremented. Is it > automatically being decremented somewhere else? > --- In , "ctrobot28" <pdm@o...> wrote: > > My little program runs from ram, the board is in EVB mode (dbug12 > in > > flash). It uses RTI interrupts, approx. as follows: > > > > volatile int foo = 0; > > > > rti_interrupt_handler() { foo = 100; } > > > > test_func() { > > enable_rti_interrupts(); > > while (foo == 0); // spin > > // continue > > } > > > > The interrupts happen, the handler runs, but the program never gets > > past the spin loop. The frequency divisor (RTICTL) is set to > 10X2^16, > > and osc_clock is 4000000, so (if I'm understanding this stuff > right) > > there should be an interrupt about every .16 seconds, i.e. pretty > low > > frequency. My only guess is that dbug12 is adding some _huge_ > > overhead to interrupt handling, so that even though my handler is > > extremely short, by the time it finishes there's another interrupt > > pending. Anyone know is this is plausible? Is there some known > > problem with using interrupts in EVB mode? > > > > Patrick |
|
|
|
I didn't know I needed to clear that flag - that must be what's happening! Thank you! --- In , "dw4guitar" <dickwebb@i...> wrote: > I see where you are changing the value of 'foo' to get out of the > loop, but I don't see in the interrupt handler where you clear RTIF. > According to the book, you need to clear RTIF by writing to the > real-time interrupt flag register (RTIFLG) with RTIF (bit 7) set. > Otherwise you have a constant flag that triggers the interrupt; as > soon as you leave the interrupt handler it is immediately called > again because of the flag. > > Hope this helps. > > -- DW |