m68k clock problem

[Joel Sherrill]

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?  

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?

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.

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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985