Re: M32C/83: problem with pointers

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Quoted text here. Click to load it

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

Markus

Re: M32C/83: problem with pointers


Quoted text here. Click to load it

 
Quoted text here. Click to load it

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] = ;


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
We've slightly trimmed the long signature. Click to see the full one.
Re: M32C/83: problem with pointers

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 ->
--

Re: M32C/83: problem with pointers

[...]
Quoted text here. Click to load it


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 ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Site Timeline