Re: [Sdcc-user] initialization of XISEG fails on ATMEL AT89C51ED2

[Frieder F. <fri...@we...>]

Hallo,

Heiko M=FCller schrieb:
> we are using sdcc 2.4.0 (debian sarge) for uC ATMEL AT89C51ED2.
> The initialization of global xdata (XISEG) is not properly performed=20
> without option '-no-xinit-opt' when the internal XRAM of uC
> is used and XISEG ends above 0xFFh.=20

the AT89C51RD2/ED2 deviates from a standard mcs51 core
with respect to its pdata addressing mode.

"Accesses to XRAM above 0FFH can only be done by the use of DPTR."
(page 25 of 08/05 datasheet)

> Looking into the *.asm output shows:
>=20
>   1  ;--------------------------------------------------------
>   2  ; File Created by SDCC : FreeWare ANSI-C Compiler
>   3  ; Version 2.4.0 Mon Nov  6 18:07:35 2006
>   4
>   5  ;--------------------------------------------------------
>   6          .module ******
>   7          .optsdcc -mmcs51 --model-small
>   8  [...]
>   9  ;--------------------------------------------------------
>  10  ; global & static initialisations
>  11  ;--------------------------------------------------------
>  12          .area GSINIT  (CODE)
>  13          .area GSFINAL (CODE)
>  14          .area GSINIT  (CODE)
>  15  __sdcc_gsinit_startup:
>  16          mov     sp,#__start__stack - 1
>  17          lcall   __sdcc_external_startup
>  18          mov     a,dpl
>  19          jz      __sdcc_init_data
>  20          ljmp    __sdcc_program_startup
>  21  __sdcc_init_data:
>  22  ;       _mcs51_genXINIT() start
>  23          mov     r1,#l_XINIT
>  24          mov     a,r1
>  25          orl     a,#(l_XINIT >> 8)
>  26          jz      00003$
>  27          mov     r2,#((l_XINIT+255) >> 8)
>  28          mov     dptr,#s_XINIT
>  29          mov     r0,#s_XISEG
>  30          mov     p2,#(s_XISEG >> 8)
>  31  00001$: clr     a
>  32          movc    a,@a+dptr
>  33          movx    @r0,a
>  34          inc     dptr
>  35          inc     r0
>  36          cjne    r0,#0,00002$
>  37          inc     p2
>  38  00002$: djnz    r1,00001$
>  39          djnz    r2,00001$
>  40          mov     p2,#0xFF
>  41  00003$:
>  42  ;       _mcs51_genXINIT() end
>=20
> The code uses movx w.r.t. r0 and p2 (lines:29-35) for writing to XISEG.=
 This=20
> does not work if XISEG is located in XRAM (internal memory) of the uC (=
as for=20
> the T89C51ED2). IMHO it would be more portable to use 'movx @dptr, a'. =
This=20
> would not depend on the physical location of the XISEG.=20
>=20
> With sdcc option '-no-xinit-opt' the initialization is done explicitely=
 by=20
> assignments and works fine, but code size is larger.
>=20
> This problem seems persistent also for the most recent sdcc v2.6.0. Is =
there
> any reasion not to change _mcs51_genXINIT() accordingly? Perhaps, I ove=
rlook=20
> some other implications?

It could be changed, but I doubt there would be a consensus
to use a more lengthy initialization routine for all devices
in order to support a specific mcs51 derivative with a
non-standard pdata addressing mode.

Newer versions of SDCC are more easy to adapt.
(In this context "Newer" denotes
"later than 2004-03-17" - see ChangeLog)

> "Englerstr. 28"

Hoppla, just seen this. This is less than 2 km line-of-sight from here!
I guess I should rather call by phone instead of writing emails!)

Gr=FC=DFe,

Frieder