Any known compiler issues for CPU32? (stack corruption problem)

[Mike Panetta]

On Thu, 2002-02-28 at 06:14, Joel Sherrill wrote:
> 
> 
> Mike Panetta wrote:

> > Well maybe,  I donno yet.  I do know that I was confused about where the
> > stack should have been after the process starts.  Its intresting what
> > you can learn after stepping through a context switch in a debugger :).
> > Apparently the stack for processes is allocated in an area at the end of
> > memory called the workspace.  So the SP being above the stack top is
> > normal if your in a process.
> 
> I don't know what has changed with your local copy of the BSP but
> the linkcmds/memory map looked to be OK.  If you have reworked the
> start code, there are a handful of common things that can go wrong:
> 
>   + not disabling interrupts 

Ill look in to this.  Is oring #0x0700 to the SR good enough for this? 
This is what the origional code did, I did not change it.  Its the first
thing it does on strtup.

>   + not initializing the memory controller correctly.

I did not change this either, but that does not mean its not wrong :). 
I did move it from what was start.c (now start.S) in the start
directory, to start_c.c in the startup directory though.

>   + bad memory map (code, data, bss, heap, starting stack, and 
>     RTEMS workspace should not overlap)

As far as I know the linkcmds file is the same for this BSP, as it is
for every other of the m68k BSPs excepting the location of ram and rom
of course.

>   + initializing the stack pointer to the wrong end of the
>     RAM reserved for the starting stack.  The stack grows down on m68k
>     so it would have to be at the high end of the memory reserved.

This part is right.  The SP is initialized to _stack_init, which appears
to be the top of the stack by looking at the linker script.

> 
> If you are tracing through the first context switch, and going 
> off in the weeds, then it is almost 100% certain that you are getting
> a spurious interrupt.  If everything in the BSP's init is working well
> enough to get to the first context switch, then that is where interrupts
> are enabled for the first time.  It is not uncommon for things to
> blow up there when an interrupt source has not been cleared/masked
> properly by the init code.

Ill have to look over the code thats there.  I had to make one change,
it was trying to print things to the console during the spurious
interrupt, there may be other things that need to be fixed.  The vector
base register is reset by the init code as well.  I should probably make
sure that its set to the right address (make sure it matches the address
of the space that has been allocated for it).

> 
> > The strange thing is, after disabling interrupt mode IO, I got the hello
> > sample to work, but after that I tried to run base_sp, and it failed.
> > Something really wacky is going on here.  
> 
> When debugging a BSP initially always do a hard reset between tests.
> Many BSPs do not clean up completely upon program exit and this clouds
> things.

Hard reset poweroff, or just reset switch type of thing?  If its just a
reset switch type of thing, the BDM pod seems to do that for me every
time I reload the code.

> 
> Are you using the old console driver?  It violated the RTEMS interrupt
> model and could cause all sorts of weird problems.

Nope.  I am using the new one you sent me.  

> 
> > I stepped all the way through
> > the code  in the Init part of base_sp, from task creation, to starting
> > the second task, to the destruction of the init task, it all seemed
> > fine, untill it tried to do a context switch to the new task, then it
> > died.  The context switch from the OS to the Init task went smoothly
> > though.  Also, running in GDB does not seem to act the same as just
> > running on the board with a breakpoint set in CPU32BUG.  The code will
> > not get as far in CPU32BUG.  Say if I put a breakpoint right at Init in
> > the code running in GDB, it may get to it.  If I put a breakpoint in the
> > exact same place in CPU32BUG, it dies before it gets to it with an
> > illegal instruction exception at 0xFFFE (or somthing like that).
> 
> Is the BSP init code preserving the debug vector number used by
> CPU32bug?
> 

I think so.  Not 100% sure on this one.  Its preserving the illegal
instruction vector atleast :).  Breakpoints do work in CPU32BUG, if
thats what your asking.  I can set a breakpoint at bsp_start for
example, and CPU32BUG will stop there.


> > 
> > I have doubled, and even quadrupled the stack, it does not help.
> 
> It won't if it is an interrupt problem.

Yeah, I did not think so, thats why I set it back...  I set it back to
8K.  Is that big enough?

> 
> > > i also seem to remember (but cant be sure), that rtems is running in
> > > priverlaged mode at this point, is it possible that come code is stomping
> > > the stack pointer ? - ive seen stranger.
> > 
> > I donno.  I cant figure it out in GDB, because the code acts different
> > in the debugger :(
> 
> Not unusual.  I really suspect a basic interrupt problem.  SOmething is
> not initialized correctly and/or there is something wrong with the 
> console driver.
> 

I will take a closer look at the interrupt init code.  I just assumed it
was correct, thinking that this BSP must have worked at some point!

> If RTEMS and CPU32bug are sharing the same serial port, you will have to
> be careful that the RTEMS handling of it does not conflict.  I suspect
> that the console driver will have to remain polled to cooperate with
> CPU32bug.

Yeah, I think so.


Mike

> 
> > Mike
> > >
> > > regards
> > >
> > > ---
> > > Matthew J Fletcher            amimjf at connectfree.co.uk
> > > Software Engineering          Matthew.Fletcher at student.shu.ac.uk
> > > www.amimjf.org                        ICQ amimjf 44193496

> 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