• State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 21 subscribers
  • Views 3874 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

when I use big arrays, i get problem...

Mustafa Koyuncu

Hi,

I am using AT89C51rd2. When I use big arrays like abc[270] and def[274] in my code, nothing works correct. But i use abc[40] and def[40], every thing is ok.

when abc[270] and def[274] declared, keil generates:

Program Size: data=109.1 xdata=1159 code=12696

when abc[40] and def[40] declared, keil generates:

Program Size: data=109.1 xdata=695 code=12461

In options, "use on-chip xram" is checked. I tried to set AUXR resiter in firmware like XRS0=0,XRS1=0,XRS2=1 to select "software selectable" xram size as 1792. Nothing is work....

What can be the problem???

Thanks...

Parents
  • 0 in reply to ImPer Westermark

    Look at the code you posted:

    XDATALEN        EQU     1792

IF XDATALEN <> 0

                mov a,8EH
                setb acc.4
                clr acc.2
                clr acc.3
                mov 8EH,a

                MOV     DPTR,#XDATASTART
                MOV     R7,#LOW (XDATALEN)
  IF (LOW (XDATALEN)) <> 0
                MOV     R6,#(HIGH (XDATALEN)) +1
  ELSE
                MOV     R6,#HIGH (XDATALEN)
  ENDIF
                CLR     A
XDATALOOP:      MOVX    @DPTR,A
                INC     DPTR
                DJNZ    R7,XDATALOOP
                DJNZ    R6,XDATALOOP
ENDIF

    XDATALEN is set to a valuse of 1792 - if you don't correctly configure the chip (via AUXR), what will happen in that loop which tries to access 1792 bytes of XDATA...?

    And that isn't the only thing!

    All of the rest of the startup code will be assuming that 1792 bytes of XRAM are available and will be trying to access them...

Reply
  • 0 in reply to ImPer Westermark

    Look at the code you posted:

    XDATALEN        EQU     1792

IF XDATALEN <> 0

                mov a,8EH
                setb acc.4
                clr acc.2
                clr acc.3
                mov 8EH,a

                MOV     DPTR,#XDATASTART
                MOV     R7,#LOW (XDATALEN)
  IF (LOW (XDATALEN)) <> 0
                MOV     R6,#(HIGH (XDATALEN)) +1
  ELSE
                MOV     R6,#HIGH (XDATALEN)
  ENDIF
                CLR     A
XDATALOOP:      MOVX    @DPTR,A
                INC     DPTR
                DJNZ    R7,XDATALOOP
                DJNZ    R6,XDATALOOP
ENDIF

    XDATALEN is set to a valuse of 1792 - if you don't correctly configure the chip (via AUXR), what will happen in that loop which tries to access 1792 bytes of XDATA...?

    And that isn't the only thing!

    All of the rest of the startup code will be assuming that 1792 bytes of XRAM are available and will be trying to access them...

Children
  • 0 in reply to Andy Neil

    Many are afraid of touching startup.a51 however in some cases it is MANDATORY.
    when the OP followed my suggestion (set AUXR in startup) everything worked.
    thus
    ANYTHING related to xdata configuration (e.g. SILabs) MUST be done at the beginning of startup
    if you have an external XDATA memory, you may need to configure the clock at the beginning of startup.
    if you have a crossbar (SILabs, some ARMs, ,,,) you need to configure it at the beginning of startup.

    Generally:
    anything that relates to XDATA access MUST be done at the beginning of startup
    this can be memory configuration, memory timing, crossbar, ....

    HAVE NO FEAR modifying startup is quite simple. DO NOT call a C routine, C is not "ready"

    Erik

  • 0 in reply to ²erik malund

    I wonder if they are actually afraid, or if they just don't think about it and/or don't realise that it's there?

    http://www.keil.com/support/man/docs/c51/c51_ap_customfiles.htm

  • 0 in reply to Andy Neil

    I guess it's more like an automatic "place all initialization at top of main" which, for some NON-51 compilers (e.g. visual C) may be totally relevant.

    There are some 'typical' 'mistakes' 99% of PC coders make when they try to be '51 programmers.

    Erik

    PS I have found "place all initialization at top of main" not to work for IAR/STM32 cortex so it's not just the '51. OK this is a Keil forum, but I work with the tools my customer gives me. Sone the issue is in the ST provided code I believe that the same holds true for Keil ARM