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

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: 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.php3Yahoo! Groups LinksTo