1. Home
  2. Embedded Programming
  3. SDCC Compiler problems - HELP!

SDCC Compiler problems - HELP!

Can anyone help with how you successfully run SDCC on a Windows XP machine and generate proper hex files?

I am starting on a project using an Atmel AT89C5131 (an 8051 derivative with a built-in USB port). I have written several small test programs in assembler and they run just fine. But all attempts to run any small test program written using the SDCC C compiler have resulted in failure. Obviously I am doing something wrong, but have no clue what.

For example, the following simple assembler program:

; Assembler code - LED Test LEDCON DATA 091H ;LED control register P1_5 BIT 095H ;P1.5 - pushbutton switch P3_7 BIT 0B7H ;P3.7 - status LED ORG 00000H ORL LEDCON, #0C0H ; Set P3.7 for 10mA LED current limit LOOP: JNB P1_5, PB_PRESSED ; Read status of pushbutton switch SETB P3_7 ; Turn LED off (set P3.7 high) JMP LOOP PB_PRESSED: CLR P3_7 ; Turn LED on (set P3.7 low) JMP LOOP END

works just fine. When the pushbutton is pressed, the LED lights. Let go and the LED goes out.

But the same program coded in C:

/* C Code - LED Test */ #define Sfr(x,y) sfr x = y #define Sbit(x,y,z) sbit x = y ^ z Sfr (LEDCON, 0x91); /* LED control register */ Sbit (P1_5, 0x90, 5); /* P1.5 - pushbutton switch */ Sbit (P3_7, 0xB0, 7); /* P3.7 - status LED */ void main (void) { LEDCON |= 0xC0; /* Set P3.7 for 10mA LED current limit */ while(1) /* endless loop */ { if (P1_5 == 0) /* Read status of pushbutton switch */ P3_7 = 0; /* Turn LED on (set P3.7 low) */ else P3_7 = 1; /* Turn LED off (set P3.7 high) */ } }

does nothing when loaded into the microcontroller. The code is self-contained (no include files) and the SDCC compiler version is

2.5.0. With both programs, I am using Flip 2.4.4 to download the hex code into the microcontroller, using the USB port. Both assembler and C hex files are downloaded the same way, but assembler code always runs and C code never does, so I believe we can rule out hardware problems and the FLIP software.

To compile the C program above, I open a DOS Box (Cmd window) and type: C:\xxx> sdcc testled.c There are no compile errors and SDCC generates all the usual files, including 'testled.ihx'.

I then type: C:\xxx> packihx testled.ihx > testled.hex which generates the 'testled.hex' file and says: packihx: read 26 lines, wrote 14: OK.

When downloaded into the microcontroller flash, the hex file does not run properly. Attempts with other simple test code written in C have failed as well. It is my understanding that SDCC generates 8051 code as a default, but just in case, adding the command line option "-mmcs51" doesn't change anything. The .lst files look okay but contain a lot of other crap which makes them difficult to read.

I know I'm being stupid and missing some step. Can anyone assist the mentally retarded?

Reply to
Desert Rat
Loading thread data ...

I've successfully used SDCC v2.5.0 on WinXP for an (8051-based) Cypress EZUSB chip. Straight-forward, nothing tricky.

I can't see/think of anything you've done wrong (although it's been a while)....

Looking at my makefile I have... FCC = sdcc FLINK = sdcc --itam-size 256 --xram-loc 0x2000 ...no other options

But I do have this in my header...

#define SBIT(addr, name) sbit at addr name #define SFR(addr, name) sfr at addr name

I also notice that the headers in sdcc mcs51/inc direectory uses __sfr__ __at 0x80 P0;

Let me know how you go... if you're still stuck and I get time I might be able to download your code to my device (changing the port definitions) and see if the leds flash there...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

I don't know this environment, but checked through your code examples... Spent a little while worrying about: #define Sbit(x,y,z) sbit x = y ^ z

The XOR (where I'd have used an OR) had me going for a while... but in context, seems fine.

I can't comment on the correctness of the macros (and the underlying directives). Can you test any other way that your program is actually running?

Is the origin of the C code setup? Does it have a stack? (Not that your code uses it, but pre-main code might.)

Steve

formatting link

Reply to
Steve at fivetrees

Mark, you hit the nail on the head with your suspicion about the syntax of the 'sfr' and 'sbit' directives. The syntax I was using was:

#define Sfr(x,y) sfr x = y #define Sbit(x,y,z) sbit x = y ^ z Sfr (LEDCON, 0x91); /* LED control register */ Sbit (P1_5, 0x90, 5); /* P1.5 - pushbutton switch */ Sbit (P3_7, 0xB0, 7); /* P3.7 - status LED */

This syntax was lifted directly from an include file currently posted on the Atmel website, which is indicated as being specifically for the AT89C5131 processor and the SDCC compiler. However, this syntax is completely ka-ka. Thanks a lot, Atmel!

Interestingly enough, the SDCC documentation for include files shows two more variations of the syntax for 'sfr' and 'sbit', though one is indicated as being "obsolete". The other, apparently current, syntax is as follows:

__sfr __at 0x91 LEDCON ; __sbit __at 0x95 P1_5 ; __sbit __at 0xB7 P3_7 ;

When I used these three lines in place of the five above, the program compiled and worked perfectly. Problem solved!

However, one must ask how can the SDCC compiler compile a program without error when the syntax is incorrect. The last time I checked, the PRIMARY job of a compiler is to check for correct syntax. I'm already unimpressed with SDCC.

Thanks for your help.

Roger

Reply to
Desert Rat

I'm sure you know that the classic compiler switch is "-Wall" (all warnings enabled).

And, of course, it's possible for such things to be syntactically correct but functionally wrong.

Glad to read you've solved the problem. I'll sleep easier.

Steve

formatting link

Reply to
Steve at fivetrees

here is good tool:

formatting link
it is MIDE-51, just install under win, and run

BR bluesboy

Reply to
Blues Boy

here is good tool:

formatting link
it is MIDE-51, just install under win, and run

BR bluesboy

Reply to
Blues Boy

Reply to
basanth

ur while statement should be b4 closing braces of main........

Reply to
basanth

The problem is the Sfr macro. From the SDCC User Guide:

Please note, if you use a header file which was written for another compiler then the sfr / sfr16 /sfr32 / sbit Storage Class extensions will most likely be /not/ compatible. Specifically the syntax sfr P0 = 0x80; is compiled /without warning/ by SDCC to an assignment of 0x80 to a variable called P0.

Replace the LEDCON declaration as follows:

__sfr __at (0x91) LEDCON;

to define an SFR variable.

Look at the asssembly code listing from SDCC to see the difference in the generated code.

HTH,

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .
Reply to
Niklas Holsti

Oh yes, also replace the sbit declarations to be:

__sbit __at (0x95) P1_5;

__sbit __at (0xB7) P3_7;

(I haven't tried these corrections on a real chip, but the disassembly looks ok.)

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .
Reply to
Niklas Holsti

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.