m68k clock problem

[Nicolas PIGEON]

Hi Joel,

>Nicolas PIGEON wrote: 
>> 
>> Hi, 
>> 
>> I still can't solve this problem, but I have some news. The _CPU_ISR_install_raw_handler works OK, I can see that the right address is writen in the clock exception vector (_ISR_Handler), and that the exception table is correctly updated with the address of Clock_isr, which calls rtems_clock_tick. The problem disappears when I disable the Timer 1 interruption by removing the line:
>> m302.reg.imr |= RBIT_IMR_TIMER1 
>> but of course, there's no clock after that. 
>>The interruption is raised precisely when the RTS instruction is executed. 

>I know you say precisely when the RTS is executed but which RTS?  


Sorry... I was talking about the Context_switch one


>If it is the one at the end of the context switch code, then this is 
>expected 
>sicne that implicitly enables interrupts which switching to the first 
>task 
>from the initialization code.  This would likely mean that the vector is 
>not going where you think it is.  The CPU is going to fetch an offset 
>from 
>0 (no VBR on this one right?).  Is the memory at 0 ROM?  Is it going to 
>an 
>RTEMS location? 


There's indeed no VBR on this processor. The vector table is located in RAM at address 0x00 (ROM starts at 0x100000), but it's not even read when the problem occurs, except for what seems to be (according to the 68302 user's manual) a "trace" exception. I'll post right now a precise explaination of what happens.


>If it is the RTS after the above |= statement and that code is in the 
>driver 
>or board initialization before the first attempt to context switch, then 
>you 
>have interrupts enabled too early.  All BSP and RTEMS initialization is 
>assumed 
>to have interrupts disabled. 

>Just two guesses. 

Thanks for your ideas !