Succes was: m68k clock problem
pigeon.nicolas at wanadoo.fr
Tue May 27 12:17:40 UTC 2003
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 !!!!
> 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):
> > 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
More information about the users