Hi everybody,
i have detected some absurd behavior in my project. In not determinated intervalls i have a repeating problem with my At89c51Re2 software.
Now i reduced the Problem to a minimum.
Anywhere in my code i add a simple global variable (like static UINT32 g_ParameterChecksum = 0;) and the following code triggered the impossible error.
static UINT8 g_DigitalByteValue = 0; ... g_DigitalByteValue = 0; if (g_DigitalByteValue != 0) { Debug_ErrorOutput("Compiler Error? @digout"); Error_FatalError(ERROR_UNKOWN); } ...
when i removed the new variable it works well.
I am use code banking,funtion pointers, interupts and Uv3 (from command line). Program Size: data=233.1 xdata=8183 const=112 code=91375 Maximum block depth: 8
i suggest that some addresses pointers are mixed up, but i does not know why.
Has somebody a hint or solution for this problem?
Thanks a lot, David
Examine the assembler produced by the compiler and, if you can, single step through it.
the assembler code seems valid.
A step by step simulation is not possible because there are too many external device, which were not emulated.
g_DigitalByteValue . . . . . . . . . . STATIC XDATA U_CHAR 0000H 1 ... ; SOURCE LINE # 60 0002 E4 CLR A 0003 900000 R MOV DPTR,#g_DigitalByteValue 0006 F0 MOVX @DPTR,A ; SOURCE LINE # 61 0007 600B JZ ?C0002 ; SOURCE LINE # 62 ; SOURCE LINE # 63 0009 7F09 MOV R7,#09H 000B FE MOV R6,A 000C 120000 E LCALL _Debug_ErrorOutputNumber ; SOURCE LINE # 64 000F E4 CLR A 0010 FF MOV R7,A 0011 120000 E LCALL _Error_FatalError ; SOURCE LINE # 65 0014 ?C0002: ; SOURCE LINE # 66
Do you run out of RAM, so g_DigitalByteValue gets placed just after last valid RAM address. Making writes go into air and reads to either give constant dummy value or possibly capacitive results on some undriven data lines?
Or alternatively - is the g_DigitalByteValue variable receiving an address that overlaps with an address touched by an interrupt routine?
Do you run out of RAM (etc)
That (in itself) shouldn't be the problem here. The disassembly shows a clear of ACC, write to memory and then a test of ACC. That is, it does not read back the contents of the memory. So even if it was writing to nowhere (or somewhere wrong), it should not affect the test.
0002 E4 CLR A 0003 900000 R MOV DPTR,#g_DigitalByteValue 0006 F0 MOVX @DPTR,A ; SOURCE LINE # 61 0007 600B JZ ?C0002 ; SOURCE LINE # 62
The variable are at the end of my xdata segment:
START STOP LENGTH ALIGN RELOC MEMORY CLASS SEGMENT NAME ========================================================================= * * * * * * * * * * * X D A T A M E M O R Y * * * * * * * * * * * * * [...] 002007H 002007H 000001H BYTE UNIT XDATA ?XD?DIGITALOUT 002008H 002008H 000001H BYTE UNIT XDATA ?XD?GETCHAR
i cant see any overlapping with interrupt variables.
But what does a potentially more advanced 8051 chip do if accesses are made to nonexisting RAM? Does there exist 8051 chips that can produce exceptions?
Next thing is that interrupts can destroy flag or register state.
I do not know. Is the AT89C51RE2 so advanced?
That would have to be a very badly written ISR :(
"That would have to be a very badly written ISR :("
Yes very badly. But in this case the issue is a program that is, for some reason, badly behaving.
0003 900000 R MOV DPTR,#g_DigitalByteValue
what you are missing is that in startup.a51 you must enable the internal XRAM (refer to datasheet).
what you should change is that you use the LARGE model, this slow down operation dramatically and increase memory use.
BTW if you had used te SMALL model you code would have worked
Erik
Thanks for your advice,
I chose LARGE as Model because of the code size criteria. If I use SMALL i should be relocate many variables and i don't know why i should do this.
Wen i am enabling the on-chip XRam (in project properties), i get many address space overflow error L107 in xdata space from linker.
Can you or somebody give me a hint to understand this problem furthermore?
I chose LARGE as Model because of the code size criteria. the 'model' has no influence on code size
Wen i am enabling the on-chip XRam (in project properties) I do not, here have a '51 toolset here, does "enabling the on-chip XRam in project properties stick the needed code into startup.a51 ?
try, instead to insert the needed SFR write at the very beginning of startup.a51.
Hello Erik,
thanks for your reply. In my experience the change in project properties "Use On-chip XRAM" only transfer the information, so address overflow can be detected.
That gaves me the opportunity to resize my Program Size: data=233.1 xdata=4553 const=120 code=93330
The first mentioned error disappear, but another error replace it. I think there are some connection between them.
I add some simple code or move it from another function and the controller does not return and hangs up or some intern variables became strange values.
i have added the code as follows in startup.a51:
AUXR DATA 8EH ; add SFR definition for AT89c51re2 ... STARTUP1: ORL AUXR,#1CH ; added to enabled internal xram
but it makes no difference.
Now I am realizing that there are some expectation gaps between me and the µVision IDE.
I checked the allocation of my program data.
In AT89C51RE2 there are 3 code bank and 1 common bank with each 32K code space.
I ve checked the memory map and the see that the common area is filled until 00F4D3.
00F4D3H 00F54AH 000078H BYTE UNIT CONST
I dont understand why this is working well or do I miss a point?
I dont understand why this is working well or do I miss a point
probably you have less than 64k code and no banking.
In AT89C51RE2 there are 3 code bank and 1 common bank with each 32K code space. NO, In AT89C51RE2 there is 128k of code space that can be configured as "are 3 code bank and 1 common bank"
In my AT89C51RE2 there are 3 code bank and 1 common bank with each 32K code space configured as shown in www.atmel.com/.../doc7639.pdf .
code size=70977 const=120
*** CODE BANK 1 *** 008000H - 00B613H
*** CODE BANK 2 *** 008000H - 00AEAAH
*** CODE BANK 3 *** 008000H - 008AAFH
*** COMMON AREA *** 000000H - 00DBDDH
When i am put more than 64 in common area the compiler detected an overflow otherwise not.
David