Tech Support > Computer Hardware > Microprocessors > Re: M32C/83: problem with pointers
Re: M32C/83: problem with pointers
Posted by Markus Zingg on July 29th, 2003


Sounds like you are messing with near / far declarations? How about
turning on mixed mode in debugger and check what the compiler
generates?

Markus

Posted by Mark A. Odell on July 29th, 2003


Enrico Migliore <enrico.migliore@fatti.com> wrote in
news:3F267744.CB3B9A03@fatti.com:

This puts the variable into the .data segment (GCC terminology), that
means it stores 1024 bytes of zero and then copies it to the location of
my_array at startup. As this adds greatly to your executable size, you can
see why initializing file-scoped variables to zero is a bad idea. If this
is block scoped, then it's okay since it does a memset at program run-time
each time it enters said block scope.

This puts the variable into the .bss segment (GCC terminology), that means
it stores only the size of my_array and memsets it to zero at system
start up.

It sounds like you need to look at the C run-time start up code, e.g.
crt0.s or cstartup.asm.

--
- Mark ->
--

Posted by Enrico Migliore on July 29th, 2003




Markus Zingg wrote:

hi Markus,

the compiler is configured to generate far pointers and all vars
are correctly allocated in the external/far RAM because, first,
the mapviewer.exe tool confirms that, and second I tested the external
RAM accesses with the scope and had no problems.



The strange thing is that if I initialize the buffer in this way, all works
fine!:


unsigned char my_array[1024] = {0};


If I don't initialize the array, the bug appear:

unsigned char my_array[1024];


thanks for your answer
Enrico




thanks M


--
************************************************** *********
* Enrico Migliore - Co-founder and Senior Software Engineer
* FATTI srl - The Service Gateway Company
* Via Donatello 48 - 20020 - Solaro - Milano - Italy
* Phone: +3902 9679 9655
* Fax: +3902 9679 9373
* e-mail: enrico.migliore@fatti.com
* http://www.fatti.com
************************************************** *********

Posted by Hans-Bernhard Broeker on July 30th, 2003


Enrico Migliore <enrico.migliore@fatti.com> wrote:

[...]
Combined with your earlier mention of having modified the startup file
to get the compiler to generate variables in external ram, this almost
certainly points the blame at those startup file modifications.
They're apparently incomplete: you're not succeeding at initializing
the segment of non-initialized data correctly.


--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.


Similar Posts