Hi Thomas,
I'm not so familiar with OSEK, but I do know the compiler/linker.
The error message you see is generated in the following scenario:
The code uses the address of an interrupt function to initialize a
global 16 bit pointer and the interrupt function is allocated non banked.
For example, in the banked memory model, the following code generates
this message for Int0 (which is allocated banked (I tried with a HCS12X
and it ended up for me at 0xFE8000)).
void __interrupt Int0 ( )
{
}
#pragma CODE_SEG NON_BANKED
void __interrupt Int1 ( )
{
}
const unsigned int OSEKOSVectorTable [ ] = {
( const unsigned int ) Int0,
( const unsigned int ) Int1,
};
Older compilers (this checking depends on the compiler, not on the
linker) did probably not set the "check overflow" flag for this case (I
say probably because I did not try it out). If you want to get the old
behavior you can move the message in the linker to a warning. But in the
long run I would make sure that your interrupt functions are allocated
non banked.
Daniel
T.Kirchmeier@[EMAIL PROTECTED]
wrote:
> Hi Ron and Rene,
>
> thanks for your help. I send the problem as bug re****t to Metrowerks
> already. During my efforts to find a solution for that another error
> occurred.
>
> First of all I describe further my project and several back ground
> information like the involving processor.
> I use the s12db128 microcontroller from Motorola for an automotive
> control device with two CAN interfaces and one SCI interface. To say it
> simple the controller should be a gateway between the three interfaces.
>
> I developed the program with the Metrowerks Compiler for HCS12
> processors (CWS-HC12-STDED-CX - compiler version 5.021 - smartlinker
> version 5.0.17). I transferred the generated code with a Lauterbach
> debugger to my target (Power Debug Interface / USB 2 with a BDM-MCS12
> interface) and everything worked fine.
> Now I supervise the same project but for an other employer. The project
> has several amplifications, so I wanted to transfer only the existing
> code first. The only difference is that I have a newer version of the
> Codewarrior (CWS-HC12-STDED-CX - compiler version 5.024 - smartlinker
> version 5.0.22). The Lauterbach debugger is the same. I didn't change
> the code to that point and I got the following link errors:
>
> Error L1907: Fixup overflow in OSEKOSVectorTable, to Can2TxInterrupt
> type 1, at offset 0x28
> Error L1907: Fixup overflow in OSEKOSVectorTable, to Can2RxInterrupt
> type 1, at offset 0x2A
>
> Also the parameter of the compiler and linker are the same. (The
> project is organize with a gnu makefile)
> CHC12.exe -Cc -Mb -F2 -DCRYPTO_AUTH_$(CRYPTO_AUTH)
> -DCRYPTO_SIG_$(CRYPTO_SIG) "-ObjN=$(OBJ_PATH)\%n.o" -WmsgSd110 -Os
>
> linker.exe "-ENVOBJPATH=$(OBJ_PATH); $(HICROSS)/lib/Hc12C/lib" -B
> $(OBJ_PATH)/template.prm
>
> The first possible error which you wrote Rene can't be the reason
> because the makefile always delete the old object files before the
> compiler starts.
> To the second point I describe more about my program. I use the OSEK
> operating system and for that it is common to apply the attributes of
> the operating system in an oil file. All interrupts, tasks and so on
> are described in this file. The OSEK configurator generates out of it
> several .h and .c files like os.h and os.c. The interrupt
> Can2RxInterupt and the OSEKOSVectorTable are both in os.c. The
> OSEKOSVectorTable contains all interrupt sources of the controller. All
> interrupts are defined as extern so you can react for these events in
> our own c-files. In my case the problematic c-file is the subcan.c
> (Can2TxInterrupt and Can2RxInterrupt are in this file)
> After I added another interrupt source like Can2ErrorInterrupt the
> linker shows me another error:
> Error L1907: Fixup overflow in OSEKOSVectorTable, to Can2TxInterrupt
> type 1, at offset 0x2C
> So on I deleted all interrupt definitions in the subcan.c file and
> moved them in another own (applmain.c). The compiler and linker
> generate the project without errors and warnings. And here comes the
> second error back to game. After the code generation I transferred it
> with the Lauterbach debugger to my target. But the program counter
> jumps always in the memory area for variables and nothing works. This
> have nothing to do with the displacement of both interrupts because I
> have the same result if I disable these interrupts.
> I hope you can help me because I have to show the function of my
> program in the next week. Thanks
>
> Yours sincerely,
> Thomas
>
|
