Re: [Fx2lib-devel] Setupdata at 0xe000

[Chris M. <ch...@ma...>]

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=0x3e00" -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=0x3e00" -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