dennis wrote:
> It seems the declarations and initialization of the xdata are what is
> breaking my firmware. The following is broken:
> > xdata BYTE buf[100];
> > xdata WORD count=0;
> If I instead initialize count to 0 inside main(), the firmware runs
> correctly:
>
> xdata BYTE buf[100];
> xdata WORD count;
> void main() {
> count=0;
> ...
>
>
> It seems that having the external initialized data (XISEG in the
> assembly) causes my problem. The funny thing is, it only breaks when
> count falls on a an address like:
> 0x64 (100)
> 0x164
> 0x264 etc.
>
> I've tried 0x162 0x166, 0x262, 0x266 etc. and those addresses are
> working properly. I can reproduce the problem exactly by simply
> starting the xram location at the broken address and removing buf entirely:
>
> // comment out buff xdata BYTE[100];
> xdata WORD count=0;
>
> Then compile: sdcc -mmcs51 --xram-loc 0x4064 ...
>
>
> So the issues is this:
>
> If my xdata variable is initialized and happens to lie on certain memory
> locations, the firmware doesn't run. I'm a little stumped as to why
> this is the case. In the mean time, I suppose I can get around it by
> initializing my variables locally instead of globally.
>
> Any thoughts as to why this is an issue? Perhaps there is a bug.
how are your initialized globals actually being initialized? are
you sure they _are_ being initialized? if your linker or runtime
startup code aren't set up correctly, then it's quite easy for
static initializations to not happen, leaving the contents of
those locations undefined.
it's also possible that uninitialized data (which, according to C
language rules, should be 0 on startup) may work correctly: i.e.,
if you never set a value in "count" at all, your code might work.
again, it depends on the C startup code.
paul
=---------------------
paul fox, pgf@...
|