Dennis Muhlestein wrote:
> I have a little test program I've been playing with to test different
> variable sizes and locations. I came across a weird situation and I'm
> hoping someone can help me explain it.
I've traced this problem down to a smaller issue.
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.
-Dennis
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
