and you apparently checked the other likely causes, you should check whether the T89C51CC02 is really seeing the same stuff you are thinking it sees. To verify that:

- Download srecord from srecord.sf.net. Do not look for anything else but srecord even if others should recommend another tool. Ignore tools that your vendor might have shipped.

- Erase the flash of the T89C51CC02

- Convert the SDCC generated hex file with srecord to something the programmer or bootloader simply has to love: "srec_cat yourfile.ihx -intel -fill 0xff 0x0000 0x4000 -o yourfile.hex -intel"

- program yourfile.hex to the T89C51CC02

- check whether the problem persists. If it persists:

- download the contents of the T89C51CC02 to anotherfile.hex . Compare the files. If the programmer does not allow to compare directly, convert the downloaded file with "srec_cat anotherfile.ihx -intel -o yetanotherfile.hex -intel" and use diff, kompare, winmerge, totalcommander or whatever tool you have at hand. (srecord would take binary/motorola/tektronix/whatever files)


If nothing unusual pops up it#s time for plan B:

You might be able to narrow down the problem by provoking SDCC with a dummy file containing:

code unsigned char test_array[128] = {1,2};
or:
code unsigned char test_array[256] = {1,2};
then:
code unsigned char test_array[512] = {1,2};
then [1024] ...

If this fails or you're otherwise able to reproduce your bug please file a bug report on http://sourceforge.net/projects/sdcc/

Greetings,
Frieder