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 ?
u runnin outa stack?
It's the compiler! It's the compiler! It's the compiler!
Sorry OP - my response has nothing to do with your problem...!
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.