improper fixup

SMALL is the 'standard' memory model, this is not your problem.
show the code for your smallest ISR

Erik

SMALL is the 'standard' memory model, this is not your problem.
show the code for your smallest ISR

Erik

#include<REGX52.h>
void setup_interrupts()
{

//enable timer 0 ,counter 1 ,external interrupt 0 & 1
EA=1;
ET0=1;
EX0=1;
EX1=1;
//external interrupts in falling edge
IT0=1;
IT1=1;
//enable overflow interrupt
TF0=1;
//setting mode
TMOD=0x1;
//start timer and counte
TR0=1;
}

int d,mode=0;
int count=14;

timer_interrupt() interrupt 1
{ count--;
if(d!=0 && count==0)
{ count=14;
d--;
} }

void delay(int a)
{ d=a;
while(d>0)
{ }
} void main()
{ setup_interrupts();
delay(10);
}

This is just a part of the main program that creates a delay of 10s !When i remove the timer interrupt part the code works fine .
The error is
*** ERROR L121: IMPROPER FIXUP
MODULE: code.obj (CODE)
SEGMENT: ABSOLUTE
OFFSET: 000BH

Thanks
Ram

timer_interrupt() interrupt 1
void timer_interrupt() interrupt 1

Erik

.
.
.
int d,mode=0;
.
.
.

void delay(int a)
{
  d=a;
  while(d>0)
  {
  }
}

You might also want to consider using the keyword volatile.

} void main()
{ setup_interrupts();
delay(10);
}

if you had followed the posting instructions (above the "Enter Message Details Below" field) your code would have come out like this and I'd have spotted a problem immediately

}
void main()
{
    setup_interrupts();
    delay(10);
}

you need

}
void main()
{
    setup_interrupts();
//    delay(10);
    while (1);
}

erik

"The error is"

as is, the code compiled just fine for me, running an old version of c51.

yes, it could have been written a little bit better.

as is, the code compiled just fine for me, running an old version of c51.
unless you are using the eval this is meaningless, the problem is related to using the eval.

Erik

"the problem is related to using the eval."

that eval is pure evil, :).

seriously, how so? which eval are you talking about?

ya you r right. prob is with the eval !
i tried the same code in uvision2 full version and its working
anyway thanks guys ! I really appreciate wat u r doin !Keep up the gud work

"i tried the same code in uvision2"

The current eval download would be uVision-4 - there are a great many things that will have changed in the 10 years or so since uVision2

Therefore I don't think that this is sufficient evidence to prove that, "prob is with the eval"

You might happen to be right - but you haven't proved it (yet).

"The current eval download would be uVision-4"

is it sufficiently understood that uVision is an IDE that invokes whatever compiler to compile one's source code.

are you suggesting that the issue is with the IDE, which by itself does NOT compile the code?

Quite possibly not.

However, the IDE and the compiler, etc, are not supplied separately - they are always bundled together.

So, to be precise, I should have said, "The current eval download would include uVision-4"

Similarly, an installation that includes uVision-2 would also include significantly different (older) versions of all the other tools (compiler, etc).

My point was that any installation (eval or otherwise) that includes uVision-4 will be very different from any installation (eval or otherwise) that includes uVision-2 - so it is not valid to single-out one being an eval as the cause of this problem.

Sorry for not making that clear.

"are you suggesting that the issue is with the IDE"

The IDE may be a problem due to the way it calls the other tools - in particular, in the defaults that it applies.

Also, the project file format has changed significantly between UV2 and UV4 - so there may be an issue in the conversion.

And, of course, the compiler, etc, will also be different.

Correction: apart from the brief period when UV4 was in beta and available as a separate download.

You don't download uVision, the IDE, standalone.

So you get an IDE and a compiler when downloading.

uVision 2 is old so that would indicate that both IDE and compiler is old.

It isn't even guaranteed that the IDE is compatible with a compiler with significant version difference, since command line parameters etc can change.

"they are always bundled together."

do you want to bet your retirement on that?

I think there was something wrong with your morning coffee.

I don't care about what people decides to mix and match on their own machines. Such problems are totally up to them. But without an XML (or similar) configuration file to describe dialog boxes and mappings between dialog checkboxes and corresponding command-line parameters, there are a definite coupling between IDE and compiler. A good reason for a commercial company to save on support costs by wasting a bit of bandwidth and publish bundles.