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:[email protected]]
Sent: Thursday, March 26, 2009 2:12 PM
To: Schwichtenberg, Knut
Cc: [email protected]
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
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
--
Joel Sherrill, Ph.D. Director of Research & Development
[email protected] 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
[email protected] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
Simulavr-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
