Re: [Simulavr-devel] anacomp getting reserved access messages

[Joel Sherrill]

Schwichtenberg, Knut wrote:
> RTFM helps :-)! The gcc-version you are using is inserting code that chages 
> reserved cells! Reading the datasheet makes it clear 0x5e is Reserved! 0x5f is 
> SREG and 0x5d is SP (not SPL/SPH) - so this depricated CPU shows cells that are 
> marked reserved, gcc inserts code that changes them and simulavrxx detects it. 
> Everything is fine!
>
>   
OK. But any idea why this instruction is hitting a reserved
address 0x5e? I must admit I don't know the CPU


58: cd b7 in r28, 0x3d ; 61
5a: de b7 in r29, 0x3e ; 62

And what causes this code to be generated? I don't see anything
that corresponds to it in main.c. Does this then qualify as a gcc bug?

$ avr-gcc --version
avr-gcc (GCC) 4.3.3
$ rpm -q avr-gcc
avr-gcc-4.3.3-1.fc10.i386

> Fast work-around: Change the CPU to M128 and ensure you also change the analog 
> comparator pin accordingly.
>
>   
You guys assume I know more about the AVR than I do. LOL!

This is my first real AVR project. RTEMS experiences
are just making the build and Tcl work go quickly.
> No simulavrxx error!
>
>   
I am glad to hear that we don't have a simulavr bug here or
in something I changed.
> > -----Original Message-----
> > From: Joel Sherrill [mailto:address@hidden 
> > Sent: Thursday, March 26, 2009 2:12 PM
> > To: Schwichtenberg, Knut
> > Cc: address@hidden
> > Subject: Re: [Simulavr-devel] anacomp getting reserved access messages
> >
> > I captured a trace and deleted all of the stuff below the error.
> > It appears to be happening very early in main.c.
> >
> > Look for RESERVED.
> >
> > --joel
> >
> > Joel Sherrill wrote:
> >     
> > > Schwichtenberg, Knut wrote:
> > >   
> > >       
> > > > Joel,
> > > >
> > > > here you find a usage for  "-W 0x20,-". 0x20 in the 
> > > >         
> > RAM-Area of the AVR is identicall to 0x00 in the IO-Space 
> > which is forbidden by most AVR's. This loop puts normally 
> > 10.000 "*" on you terminal. Maybe it's in there to delay or 
> > only to confuse the maintainer ;-). 
> >     
> > > >     
> > > >         
> > > I thought of that but there was no way to turn that on via Tcl
> > > until I did my work.  So I guess this is just a left over 
> > >       
> > hunk of code.
> >     
> > >   
> > >       
> > > > BTW: The comment block at the top of the source is fully 
> > > >         
> > nonsense in conjunction with the source code.
> >     
> > > >   
> > > >     
> > > >         
> > > :)
> > >   
> > >       
> > > > The 0x5e - I'm guessing - might have to do with compiling 
> > > >         
> > the source for CPU A and using it on CPU B, is it?
> >     
> > > >   
> > > >     
> > > >         
> > > The reserved message can also come out when the CPU
> > > .cpp file has temporarily marked it as such.
> > >
> > > set dev1 [new_AvrDevice_at90s4433]
> > >
> > > And this code is in that cpu
> > >
> > >         rw[0x5e]= new RWReserved(this);
> > >
> > > Is this a known register name?
> > >   
> > >       
> > > > Knut
> > > >
> > > >         
> > ----------------------------------------------------------------------
> >     
> > > > This mail is made from 100% recycled electrons. 
> > > >
> > > >   
> > > >     
> > > >         
> > >
> > > _______________________________________________
> > > Simulavr-devel mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/simulavr-devel
> > >   
> > >       
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > address@hidden        On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >    Support Available             (256) 722-9985
> >
> >
> >     


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