debug variant & 302 timers

[Antti P Miettinen]

Once upon a time Joel wrote
> OK.  Running at a -O1 is not great but running the debug variant is
> a killer!!!  On each malloc/free, the heap is walked.  

Hmm.. should building with `make VARIANT=DEBUG' cause RTEMS_DEBUG to
get defined? It does not for me. Is this dependent on some config time
option?

I just ran tmoverhd and noticed a problem in the timer driver while
running the optimized variant. I consistently got vector 0x40
interrupt at exactly the same location in the test. The program
counter was at

    m302.reg.tmr2 = 0;			/* disable timer */

in Timer_initialize() in timer/timer.c module. The module is
practically identical to ods68302 and gen68302 so I wonder whether
this kind of behaviour is possible for other people too.

My GIMR is programmed to give 0x40 as the base for IMP interrupts, so
vector 0x40 would mean that the interrupt source is "error". I did not
find exact info about this vector in my 302 manual other than that
(chapter 3.2.4, page 3-25): "When the core initiates an interrupt
acknowledge cycle for level 4 and there is no internal interrupt
pending, the interrupt controller encodes the error code 00000 onto
the five low-order bits of the interrupt vector.".

Could it really be that clearing tmr2 at suitable moment causes this
kind of behaviour? I added masking the TIMER2 interrupt to the start of
the function and after this also the optimized variant of tmoverhd ran
OK, but of course it might be just that the timing changed suitably.

I think the TIMER2 interrupt should also be masked in Read_timer while
calculating total from tcn2 and Timer_interrupts.