Succes was: m68k clock problem

[Joel Sherrill]

Nicolas PIGEON wrote:

>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 !!!!
>  
>

Chris, is this a generic problem or something that should be obviously 
user controllable?

--joel

>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
>>
>>    
>>
>>
>  
>