Hi,
Hi although it's probably not the thing that is cosing you this
problems, but XRAM starts at location 0x0000 on your device.
--
Peter
On Nov 10, 2007 2:58 AM, Eric Jonas <[EMAIL PROTECTED]> wrote:
> 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
>
--
http://www.pkuhar.com/
skype: pkuhar
-------------------------------------------------------------------------
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
