m68k clock problem

Chris Johns cjohns at cybertec.com.au
Tue May 27 09:56:33 UTC 2003


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




More information about the users mailing list