Apologies, re-sending from correct account. On Fri, 2011-09-16 at 21:55 +0200, Maarten Brock wrote: > And how is that xdata filled? SDCC assumes the code > memory is stored in a ROM-like memory and xdata is > volatile. So during startup it copies initialized data > from code to xdata. So you have two copies in memory and > thus your memory footprint has grown. If you use --no- > xinit-opt it is not copied but initialized by lots of > instructions, usually taking even more code memory. > > I guess it works because SDCC's initialization code > copied it from lower memory to xdata at 0xe000. I also > guess you missed the downside. > My compile lines look like this:
sdcc -mmcs51 --code-size 0x3c00 --xram-size 0x0200 --xram-loc 0x3c00 -Wl"-b DSCR_AREA=0xe000" -Wl"-b INT2JT=0x3f00" -DEEPROM -c --disable-warning 85 -I sdcc -I../../../3rd/fx2lib/include -I../../../common firmware.c And my link lines look like this: sdcc -mmcs51 --code-size 0x3c00 --xram-size 0x0200 --xram-loc 0x3c00 -Wl"-b DSCR_AREA=0xe000" -Wl"-b INT2JT=0x3f00" -DEEPROM -o firmware.hex app.rel firmware.rel infra.rel jtag.rel prom.rel sync.rel descriptors.rel -L../../../3rd/fx2lib/lib fx2.lib I tried a RAM-load and a 0xC2 EEPROM load. The final 0xC2 record for *code* does a load of 0x185 bytes at 0x21AB. That is immediately followed by a 0xC2 record to load 0xB8 bytes of xdata at 0x3f00, followed by a 0xC2 record to load 0xAC bytes of xdata descriptors at 0xe000. This is naturally before any SDCC init code has been called. The init code I get from SDCC (2.9.0) looks like this: 894 ;-------------------------------------------------------- 895 ; global & static initialisations 896 ;-------------------------------------------------------- 897 .area HOME (CODE) 898 .area GSINIT (CODE) 899 .area GSFINAL (CODE) 900 .area GSINIT (CODE) 901 .globl __sdcc_gsinit_startup 902 .globl __sdcc_program_startup 903 .globl __start__stack 904 .globl __mcs51_genXINIT 905 .globl __mcs51_genXRAMCLEAR 906 .globl __mcs51_genRAMCLEAR 907 ; firmware.c:35: volatile bit dosud=FALSE; 908 clr _dosud 909 ; firmware.c:36: volatile bit dosuspend=FALSE; 910 clr _dosuspend 911 .area GSFINAL (CODE) 912 ljmp __sdcc_program_startup 913 ;-------------------------------------------------------- 914 ; Home 915 ;-------------------------------------------------------- 916 .area HOME (CODE) 917 .area HOME (CODE) 918 __sdcc_program_startup: 919 lcall _main 920 ; return from main will lock up 921 sjmp . > SDCC does not support the concept of preinitialized > xdata as the FX2 has when it gets the firmware from the > driver or the I2C eeprom. > You're the last person in the world I would want to argue with about SDCC, but my observations *appear* to contradict you: * xdata is initialised with explicit values at 0x3f00 and 0xe000 by the RAM load and 0xC2 EEPROM load before any SDCC-generated code executes * When the firmware starts up, it initialises only the globals declared as 'bit' before calling main(). * There is only one copy of the descriptor values in the 0xC2 records, targetting 0xe000 directly; no copying appears to be done by the SDCC startup code. > > FWIW, I just tried the code->xdata + DSCR_AREA=e000 change on the > > firmware in FPGALink[2] and it works fine. > > Are you using C0 or C2 mode? C2 mode cannot load 0xe000 > according to the datasheet. Can the driver download to > 0xe000 directly? > A 0xC2 loader can definitely target 0xe000. There's a note in section 3.4.3 of the TRM: Serial EEPROM data can be loaded only into these three on-chip RAM spaces: * Program / Data RAM at 0x0000-0x1FFF * Data RAM at 0xE000-0xE1FF * The CPUCS register at 0xE600 [bit 0] (Actually the TRM is a bit wrong here because it can actually load program/data RAM at 0x0000-0x3fff, not 0x0000-0x1fff, but the point about 0xe000-0xe1ff stands). Chris ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Fx2lib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
