Succes was: m68k clock problem

[Nicolas PIGEON]

YESSS !!! That was the problem, I just found it!!!
In the file m68k/ods68302/startup/cpuboot.c, the GIMR is given the value 0, and it's never changed later. Thus, when a timer exception occurs, the exception vector used is 00001001 (binary) instead of the expected 10001001 (=0x89, the timer 1 exception in ckinit.c). Setting the GIMR at 0x0080 solved this.... Maybe it should be corrected in a future release?

Anyway, thanks a lot averybody for your replies, it really helped me and I learnt a lot of things!! Once again, Thank you !!!!

Nicolas


> Message du 27/05/03 12:12
> De : Chris Johns <cjohns at cybertec.com.au>
> A : pigeon.nicolas at wanadoo.fr
> Copie à : rtems-users at oarcorp.com
> Objet : Re: m68k clock problem
> pigeon.nicolas at wanadoo.fr wrote:
> > 
> > I'm using an external logic analyzer to monitor the signals, I don't use the GDB stub.
> > I'll try to explain what happens. Here's what I see on the logic analyzer (RAM=0x00000000, ROM=0x00100000):
> > 
> 
> Ok.
> 
> > 00107d24: <_CPU_Context_switch>:
> > 107d24:     moveal  %sp@(4),%a0          | OK, reads a value from the stack in RAM
> >                   movew  %sr,%d1                  | OK
> >                   andiw  #0x2fff,%d1               | to make sure that tracing is disabled, but it's the same with or without this line
> >                   moveml  %d1-%d7/%a2-%sp,%a0@      |OK, values are copied in RAM. The old stack pointer is 0xab60
> >                   moveal  %sp@(8), %a0         | OK, value copied from RAM
> > 00107d36: <restore>:
> > 107d36      moveml  %a0@,%d1-%d7/%a2-%sp  |values are copied from RAM, the new stack pointer is 0x146d0
> >                   andiw  #0x2fff,%d1               |disable tracing
> >                   movew  %d1, %sr                 | new status register
> > 
> > And now the problem comes... (Address bus=AB, data bus=DB):
> > AB=0x00107d28        DB=4e75               | the opcode of the RTS instruction is fetched
> > AB=0x00107d2a        DB=0000               | nothing in ROM here, but this 32 bits processor fetches the instructions two by two, so don't care
> > AB=0x000146ce        DB=7d28               | read a byte of the return address from the stack, it seems to be the lower byte of the instruction "movew %sr,%d1" in _CPU_Context_switch
> > And the exception seems to occur here, the processing begins...
> > AB=0x000146ca        DB=2000
> > AB=0x000146cc        DB=0010              | read a value from the stack
> > AB=0x00000024        DB=0010
> > AB=0x00000026        DB=0514              | read the exception vector n°9 in RAM (the clock interruption vector is n°137...), points to address 0x100514 (in ROM) where the unhandled exception handler resides (not the RTEMS one).
> > And then the exception is processed.......
> > 
> 
> Vector 9 is the trace exception. I do not think this is actually occuring happening.
> 
> It just so happens Timer 1 has a vector encoding of 9. This value is 
> concatenated to the V7-V5 bits of from the GIMR. It looks like these bits are 0. 
> If the GIMR is not set the vector returned is 0xf (uninitialised interrupt).
> 
> What are you setting the GIMR register too ?
> 
> 
> -- 
>   Chris Johns, cjohns at cybertec.com.au
> 
>