Okay, I've reduced this to the smallest possible example that shows the
problem:
maintest.c:
#include <C8051F340.h>
__xdata char buffer[500];
void general_setup()
{
OSCICN = 0x83;
OSCICL = 0x00;
PCA0MD &= ~0x40;
}
void configure_port()
{
P0MDOUT |= 0x0F; // port 0 is Push-Pull
P1MDOUT |= 0xFF; // port 0 is Push-Pull
}
int main(void)
{
general_setup();
configure_port();
// enable crossbar
XBR1 |= 0x40;
for(;;) {
P0_1 = 0;
P0_1 = 1;
}
return 0;
}
I compile with:
sdcc -M -mmcs51 --model-small --debug --xram-loc 0x100 --stack-auto
maintest.c > maintest.d
sdcc -mmcs51 --model-small --debug --xram-loc 0x100 --stack-auto -c
maintest.c
maintest.c:43: warning 126: unreachable code
sdcc -o maintest.ihx --model-small --debug --xram-loc 0x100
--stack-auto maintest.rel
Then I download to my device. When the buffer array size is < ~100
bytes, or absent, the for loop in main runs and P0.1 toggles, which I
can easily see on my scope.
BUT with the buffer line written as is, the code never gets to that
spot. Diffing the resulting ihx files, I see:
13,14c13,14
< :030022006475AA58
< :0A00250001E493F2A308B8000205FD
---
> :03002200F475AAC8
> :0A00250002E493F2A308B8000205FC
19,20c19,20
< :08004E007864E84400600C79BD
< :0B00560001900100E4F0A3D8FCD9FAEF
---
> :08004E0078F4E84401600C792C
> :0B00560002900100E4F0A3D8FCD9FAEE
Hypotheses:
1. perhaps on this 8051 implementation, code and data space actually
occupy the same physical ram, just at different locations? (I think the
cypress EZ-USB FX2 8051-core is like this) Nope, tripe-checked the
datasheet, the code space is in flash, which cannot be written by normal
programs except through some convoluted register-indirection scheme.
2. a bug in the code that uses the end of the xdata segment. There
appear to be:
-------- --------------------------------
0C:0037 __mcs51_genRAMCLEAR
0C:003D __mcs51_genXRAMCLEAR
in my .map, which I assume clear xram on startup? I looked at the
relevant .asm files in the sdcc lib distribution, but my 8051 assembly
isn't quite sharp enough to make heads or tails of it.
3. Some strange, chip-specific bug that I haven't thought of yet?
Thanks again! I feel like I'm closing in on whatever's wrong here...
...Eric
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
