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

[Mike Panetta]

This time it wasn't a misprogrammed memory controller :).  I tried my
hunch, and disabled interrupt driven SIO, and used polled mode
instead...  It does not break any more :)  I wonder what could cause
this...  Executing instructions and reading data from an 8 bit bus
(short and longword operands in particular) would not cause a problem
during an interrupt would it?  On the 68K are long or short operand
fetches on a byte bus divisible?  Would this mess up anything that
expected a long or short access to be atomic?  Maybe I am just jumping
to conclusions and the ISR is foobared :P  The reason I even thought of
this is the MRM, unlike the MVME147SA that I ran the other tests on, has
only an 8 bit bus for both instruction and data fetches.  One other
conclusion is the interrupt arbitration register for the SCI is
misprogrammed to a value that is in some other modules interrupt
arbitration reg, which according to the manual causes "unexpected
operation".

Thanks,
Mike

On Wed, 2002-02-27 at 14:50, Joel Sherrill wrote:
> Eric Norum wrote:
> > 
> > On Wednesday, February 27, 2002, at 12:51 PM, Mike Panetta wrote:
> > 
> > >
> > >
> > > Are there any known compiler issues when generating CPU32 code with the
> > > rtems binutils-2.11.2-1 or the rtems gcc2.95.3newlib1.9.0-3?  I am
> > > getting stack corruption on one machine, that I am not on another, both
> > > m68k, but one is 68030 and the other is 68332 based.  I do not think the
> > > corruption is occuring in BSP specific code, and since the RTEMS main
> > > code works on one machine and not the other, I am beginning to suspect
> > > the compiler.  So if anyone has had problems with the above compiler on
> > > a CPU32 based machine, or just know (because they are intimate with the
> > > compiler) that there are bugs with it for CPU32, please tell me :)  If
> > > anyone has an idea on how I could track down this stack corruption
> > > problem, I would love that kind of info too :)
> > >
> > >
> > 
> > One can never be 100% sure about this sort of thing, but I can say that
> > I've run scores of applications, some very large (1.2 MBytes of code,
> > 10s of thousands of lines) without difficulty on CPU32 machines using
> > the above toolchain.
> > 
> > Can you use BDM on the CPU32 to step through the code and narrow down
> > the location where the problem occurs?
> 
> 
> If the problem is on the 68332 board, then misprogramming the 
> memory controller can shoot your feet out from under you.  :)
>  
> > Eric Norum
> > eric.norum at usask.ca
> > Department of Electrical Engineering       Phone: (306) 966-5394
> > University of Saskatchewan                        FAX:   (306) 966-5407
> > Saskatoon, Canada.
> 
> -- 
> 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