I think
that this version of the Metrowerks linker does not properly flag a warning that
the program area has been overflowed. The only way to determine is to look at
the map file.
I
don't know what linker command file you are using, but if it is from the
SDK their is a section for pFlash2. I think that since the memory is not
contigous that the linker is not smart enough to automatically use the second
section. You need to list the specific files that you want to be placed in the
second flash block. If you are using the SDK linker command file go to the
pFlash2 section and add the file names as directed to use the second flash
block. If you are not currently targeting any of the files to the second flash
block then modifying the linker command file to use the second flash
block will probably solve the problem.
Also the initialized
variables can be placed into either porgram or data flash. So if you are running
out of program flash area you can instead place the variables in data flash.
This requires you to set up the linker command file to place the initialized
variables in the data flash. The SDK targeting manual for the 56F826/827 chapter
3.4 has a very detailed description of what is in the linker command file and
how to modify it.
Thanks.
-
Bill
-----Original Message----- From: bmbmz123
[mailto:b...@mer.co.il] Sent: Tuesday, February 03, 2004 8:00 AM To: m...@yahoogroups.com Subject: [motoroladsp] DSP56F827:
Flash to RAM copy - Compiler Overflow w/o Error?
Hi all, I've come across a
problem.
The sw has some constant data, which is copied after reset
from pflash to RAM, as one big block - the data is mirrored to RAM.
It seems that the this constant data block is placed after the sw in pflash.
Now, that the sw is large, and there are many constants, it
looks that the constant data block has overflowed the pflash boundry!
I came across this when some constant data was bad. As I
check with the debugger, I saw that some data was ok, up to a point, and
from that address on, there was bad constant data.
I looked at the
MAP file, and measured that constant data block after the last sw routine
address, and it is overflowed!!
Why didn't the compiler shout an
error? Has anyone seen this before?
As the '827 has another
pflash2 memory, will the compiler know to place an even larger sw in the
two pflas sections?
I'm using CW ver 4.1 (a bit old, I know!)
boaz
_____________________________________ Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.
_____________________________________ About this discussion group:
Reply by Dobsik Lubomir-RC085C●February 4, 20042004-02-04
I think
the problem could be in using the 'AT' linker command, which
places a section to an arbitrary address. The CodeWarrior linker correctly
reports an overflow of a section, but has no means how to check if the memory
area where you place a section physically by the 'AT' command is
already used or out of scope of a memory segment.
Lubomir
-----Original Message----- From: Bende Georg
[mailto:g...@faulhaber.de] Sent: 4. ora 2004 16:05 To:
Pete Becher; m...@yahoogroups.com Subject: AW: [motoroladsp] Re:
DSP56F827: Flash to RAM copy - Compiler Overflow w/o Error?
I think rather this is a problem in the linker.cmd file you
have. For me it indicates the memory overrun, but I have defined an own region
in the linker command file and it works this way. (But with dynamic assignment
this feautre doesn't work.)
Georg Bende Softwareentwickler Abteilung Elektronik Dr. Fritz Faulhaber GmbH
& Co KG Daimlerstr. 23 71101 Schaich Tel: +49 7031
638294> -----Ursprgliche Nachricht----- > Von: Pete Becher
[mailto:p...@dynatronix.com] > Gesendet: Mittwoch, 4. Februar 2004
15:43 > An: m...@yahoogroups.com > Betreff: [motoroladsp] Re:
DSP56F827: Flash to RAM copy - > Compiler Overflow w/o Error?> Hi
Boaz, > > Yes this is a problem in CodeWarrior. It does
not flag any memory > overruns. The problem is still in version
5.1 and I have not seen > any indication that it has been fixed in
version 6.0. I had > contacted tech support about this problem a
while back. Maybe > someone from Metrowerks can confirm whether
or not this is fixed or > will be fixed. > > Pete>
--- In m...@yahoogroups.com, "bmbmz123" <boaz_b@m...> wrote: >
> Hi all, > > I've come across a problem. > > > > The sw has some constant data, which is copied after reset from > > pflash to RAM, as one big block - the data is mirrored to RAM. > > > > It seems that the this constant data block is placed
after the sw > in > > pflash. > > >
> Now, that the sw is large, and there are many constants, it looks > > that the constant data block has overflowed the pflash boundry! > > > > I came across this when some constant data was
bad. > > As I check with the debugger, I saw that some data
was ok, up to a > > point, and from that address on, there was bad
constant data. > > > > I looked at the MAP file, and
measured that constant data block > after > > the last sw
routine address, and it is overflowed!! > > > > Why
didn't the compiler shout an error? > > Has anyone seen this
before? > > > > As the '827 has another pflash2
memory, will the compiler know to > > place an even larger sw in the
two pflas sections? > > > > I'm using CW ver 4.1 (a
bit old, I know!) > > > > boaz>
_____________________________________ > Note: If you do a simple "reply"
with your email client, only > the author of this message will receive
your answer. You > need to do a "reply all" if you want your
answer to be > distributed to the entire group. > >
_____________________________________ > About this discussion group: > > To Join: m...@yahoogroups.com > > To
Post: m...@yahoogroups.com > > To Leave:
m...@yahoogroups.com > > Archives:
http://www.yahoogroups.com/group/motoroladsp > > More Groups:
http://www.dsprelated.com/groups.php3 > > >
Yahoo! Groups Links > > To