m68k clock problem
pigeon.nicolas at wanadoo.fr
Fri May 23 15:18:26 UTC 2003
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
> > 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
More information about the users