Hi All,
I'm experiencing a strange behiver in the following flow:
code compiles ok and run ok: C:000000H C:000000H C:00FFFFH 000935H CODE I:000000H I:000000H I:0000FFH 000018H IDATA I:000000H I:000000H I:00007FH 000048H DATA C:000000H C:000000H C:00FFFFH 0002C0H CONST X:000000H X:000000H X:00FFFFH 000024H XDATA
Program Size: data=96.0 xdata=36 const=704 code=2357 LX51 RUN COMPLETE. 4 WARNING(S), 0 ERROR(S)
but adding only another char without even code (DATA incress to 49) results with stack problem that RET is jumping to unused address and programs fails.
C:000000H C:000000H C:00FFFFH 000935H CODE I:000000H I:000000H I:0000FFH 000018H IDATA I:000000H I:000000H I:00007FH 000049H DATA C:000000H C:000000H C:00FFFFH 0002C0H CONST X:000000H X:000000H X:00FFFFH 000024H XDATA
Program Size: data=97.0 xdata=36 const=704 code=2357 LX51 RUN COMPLETE. 4 WARNING(S), 0 ERROR(S)
Can someone tell me what could be wrong ?
IDE-Version: µVision V4.10 Copyright (C) 2010 KEIL, An ARM(R) Company
Tool Version Numbers: Toolchain: PK51 Prof. Developers Kit Version: 9.02 Toolchain Path: C:\Keil\C51\BIN\ C Compiler: C51.Exe V9.02 Assembler: A51.Exe V8.02 Linker/Locator: LX51.Exe V4.47a Librarian: LIBX51.Exe V4.24 Hex Converter: OHX51.Exe V1.38 CPU DLL: S8051.DLL V3.73 Dialog DLL: DCORE51.DLL V2.73 Target DLL: BIN\DCD_DoCD_USB.DLL V2.62 Dialog DLL: DCORE51.DLL V2.73
same code with less variables works fine. adding a variable will result a got compile but running to a RET back to main function will result a jump to non valid address.
anyone ??
.... which only has 128 bytes of (I)data
what is the EXACT chip you use ALL letters/numbers
Erik
DCD DP8051
u probly runnin outa stack so go chek it
check the datasheet for (I)data size, if 128 this is your problem
Hi,
DCD DP8051 uses 256B, How to check stack overflow ??
There several good posts about checking stack overflow. Just search this forum which I won't do for you. But a quick paraphrase of the posts. Go to your map file and locate the stack assigned location in memory. In the debugger, execute a run to main then fill the stack area with something like 's'. Run your code to failure and look at the mapped stack area. Are all of your 's' overwritten?
Any 's' reamining will show the end of stack usage. Bradford
Problem solved,
The start.A51 was wrong and the SP was not updated correctly, variables were overun.
Thanks,
The start.A51 was wrong and the SP was not updated correctly,
A claim easily made --- but much less easily substantiated. So: what was "wrong" about that startup code, and what was the fix?
SP loc is calculated in a51 startup code, I ignored the a51 file and such placed the SP in low address the was overrun by variables.
Hope It cleares my problem and sulution.
No, it doesn't. You're being rather excessively vague.
As a matter of fact, the startup code(s) provided by Keil all initialize the SP to the start of the unused portion of IDATA, as it should be. The stack grows upward from there, until it hits the wrap-around barrier at 0xff. You modify that mechanism at your own peril, especially if you don't know exactly what you're doing.
I did change that file. The code at first look as a zero mem util. As I wanted to avoid xdata loop calls and save some time I avoided the A51 with a bypass.
This was a mistake as the SP was not updated.
So, form this post I recommend to carefully remove the XDATA zero calls only if you want to save running time and not cancel it out all together.
Hop now its clear.
The code at first look as a zero mem util.
That's because zeroing static variables is one of several jobs the startup file has.
As I wanted to avoid xdata loop calls and save some time
Doing that will hardly ever save any time. The startup code only loops over XDATA if you use XDATA in your program --- it's clever enough as-is to disable the entire loop if you don't use any XDATA. And unless you're comfortable with your code working with random garbage data, you need to initialize those variables at some point. And whichever way you eventually do that --- it will quite certainly take longer than the way the startup code would have done it.
...as it should be
Very questionable extension to the sentence. There is no rule that says it MUST be put there. It is only a reasonably sensible option that Keil (amongst others) have chosen.
You modify that mechanism at your own peril, especially if you don't know exactly what you're doing.
Absoultely. Someone who knows what they're might have reason to make these changes. It is unlikely that a beginner could conceive a true advantage.
The reason to bypass the code was to save time and avoid xdata reset as it was mapped to already initialized HW. The way to do it is to remark the movx operation and not jump directly to start.
That said, Thank you all for the replies.
The way to do it is to remark the movx operation and not jump directly to start.
May I remark that I do not know what you mean. comment out??? delete??? something else???