Re: M32C/83: problem with pointers

Enrico Migliore wrote in news: snipped-for-privacy@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.

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

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.