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...
when I define a variable which is not used in code why do you "define a variable which is not used in code"
and when it exceed 768 byte xram, it starts to make problem. how do you see that "it starts to make problem" also see below
It look like a memory allocation problem, and indirect addressing does not work good for exceeding 768bytes. it does not matter if addressing is indirect or not, if the memory is there
So i tried to set AUXR resigter as XRS0=0, XRS1=0, XRS2=1 but it did not work... where in the code, hopefully in startup.a51. also what is the XDATA size set to
Am I wrong? I am expecting a way to solve this problem... expecting??
Erik
-why do you "define a variable which is not used in code"- to test if does it make a problem.
-how do you see that "it starts to make problem" also see below- For example, xdata=900, it make small problems. Uart commands answers back but not true. For xdata=1159, nothing works, no answer...
-it does not matter if addressing is indirect or not, if the memory is there- it was just a opinion.. ;)
-where in the code, hopefully in startup.a51. also what is the XDATA size set to- at the beginning of the main. i did not know that startup code make this.
So...?
-how do you see that "it starts to make problem" also see below- For example, xdata=900, it make small problems. Uart commands answers back but not true. For xdata=1159, nothing works, no answer... that is rather arbitrary that "something falls apart when I'm doing something else" is about the most worthless diganostic there is make a piece of code that writes and reads back from, say address 500, then address 1000
i did not know that startup code make this.
make it do it
I would not be surprised if selecting RD2 automatically set it for 756 bytes
just a note
make a renamed copy of startup.a51 and include it in your project
Finally problem is solved.. :)))
Firstly I had change just XDATA lenght, but it did not work. Then I tried to add some assembly code at the beginning of the place which XDATA space cleared in startup.a51. Then is OK...
Thanks for all replies.....
Here is the code that I added:
This code set AUXR to 1792 bytes XRAM....
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
Well done, and thanks for sharing the solution - too many people never bother to do that.
:-(
In your very first post, you said,
"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...."
So what was the difference between what you tried then (that didn't work), and what you have done now (that does work)?
before, I wrote the code to set AUXR in (beginning of) main (as C code), and it did not work... but then I made it in startup and it is ok...
Do you now understand why that's a bad idea?
It would also be a goos idea to comment your additions to the startup file - both to remind yourself why it's there, and what it does...
I do not understand what was the bad idea?
Would it make a difference if you configure this setting before or after the startup code initializes all variables stored in this memory region?
Look at the code you posted:
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...
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"
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
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.
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