m68k clock problem

[Nicolas PIGEON]

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.

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

Thanks a lot


> Nicolas PIGEON wrote:
> > Hi,
> > 
> > It seems I have a little problem with the ods68302 clock driver. Let me explain:
>  > I managed to run hello.exe, but as soon as I try to run a sample using the clock 
> driver,
>  > which defines CONFIGURE_TEST_NEEDS_CLOCK_DRIVER or uses its own driver table, 
> there's a
>  > "trace" exception (vector number 9) when the 68302 returns from the first call to
>  > Context_Switch (in Thread_start_multitasking). I forced the 68000's trace bit to 0,
>  > but it's the same. I checked if the clock driver's interrupt vector was OK, and
>  > it is (it refers to _ISR_Handler). I really don't understand what happens, and
>  > I would really appreciate any help or idea....
> >
> 
> Would it be possible to get the gdb stub working ?
> 
> It is part of BSP sources and would making getting past this point easier.
> 
> > Thanks!
> > 
> > PS: For those who are using the ods68302 BSP, the reset.S file doesn't seem to work when
>  > configuring the stack pointer. I'll post a patch ASAP
> > 
> 
> Please raise a PR and attach the patch.
> 
> -- 
>   Chris Johns, cjohns at cybertec . com . au
> 
>