m68k clock problem

[Chris Johns]

Nicolas PIGEON wrote:
> 
> 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.
>

As Joel said the enabling of interrupts as a result of the first context switch 
most likely the source of the problem.

If you have the GDB stub working you should be able to 'stepi' into the context 
switch and see what is happening.

I assume you have a vector table at address 0 (VBR = 0). When you say 
_CPU_ISR_install_raw_handler works ok, I assume the real vector table entry is 
pointing to the _CPU_ISR_jump_table entry that creates the suitable stack frame 
for _ISR_Handler.

   VBR[256] -> _CPU_ISR_jump_table[256] -> _ISR_Handler

and VBR = 0.

The 68000 does not store the vector number in its default exception stack frame. 
The _ISR_Handler routine expects this. Instead of extra code and paths in 
_ISR_Handler, a 68000 has the extra redirection through the _CPU_ISR_jump_table.

 >
> Please, I REALLY need some help, I have been stuck for a week now, and my internship
 > will end soon... If you have any idea, don't hesitate !!!
>

The reasons for the interrupt failing can be summed with:

1) The real vector table not being set up correctly.
2) Invalid device programming thats generates a different exception than the one 
you have caught. For example on the 68302 you have a vector base register in the 
SIM.
3) The stack is invalid and generates a bus error. In this case you will get a 
double bus error and the processor will halt.

I would catch every vector you can with a default handler and point to something 
that shows what went off. The trace.c file in the BSP should help here. You need 
to watch the MBAR vector location and make sure you leave this one alone. The 
GDB stub has examples of what you need to do to catch all vectors.

I hope this helps.

-- 
  Chris Johns, cjohns at cybertec.com.au