Hi Bruno

Actually, the first two lines looks okey but the third line does not make sense since it includes data at the same address as line 2.

Anyway, let's dig deeper.

After som tests I was able to reproduce the problem in a simple testapplication, I also managed to go around the problem so it will not cause any big problems for me any longer. But there is obviously a problem with the omf2hex app or in the linker. Anyway, here is a description.

1. Create a new project for the STM8S208CB MCU
2. Choose the "Large ROM model"
3. Default global memory class "Data"
4. Add this file, main.c , to the project. The content of the file looks like this.

#include

int putchar(char c)
{
static unsigned char buffer[0x100];
static unsigned char idx = 0;

buffer[idx++] = c;
return 1;
}

at 0x10000 int main(void)
{
printf("Hello Raisonance\n");
_check_crc16x_();
while(1);
return 0;
}

5. To the "linker options/additional options", add this entry: CRCRANGE(0x8000, 0x1FFE0)

6. Build!

The map file looks like this

LINK MAP OF MODULE: C:\SRC\TEST4\APPLICATION0.AOF (MAIN)

TYPE BASE LENGTH RELOCATION SEGMENT NAME
---- ---- ------ ---------- ------------

* * * * * * * * D A T A M E M O R Y * * * * * * * *
DATA 000000H 000004H PAGE0 CSTDLIB_REGISTERS
DATA 000004H 000001H INSECTION0 ?ZDT?MAIN
DATA 000005H 000100H INSECTION0 ?EDT?MAIN
000105H 0012FBH *** GAP ***
DATA 001400H 000400H UNIT ?C_STACK?SEG

* * * * * * * * C O D E M E M O R Y * * * * * * * *
CODE 008000H 000004H AT ?CO?STARTUP_Z00
008004H 00007CH *** GAP ***
CODE 008080H 00003FH INSECTION0 CSTDLIB_CRC16
CODE 0080BFH 000024H INSECTION0 CSTDLIB_PUTS
CODE 0080E3H 00001BH INSECTION0 CSTDLIB_MULU1616
CODE 0080FEH 00001AH INSECTION0 CSTDLIB_SLL328
CODE 008118H 000018H INSECTION0 CSTDLIB_ADD3232
CODE 008130H 00000EH INSECTION0 CSTART
CODE 00813EH 00000DH INSECTION0 ?STR?MAIN
00814BH 000001H *** GAP ***
FCODE 00814CH 0000E8H INSECTION ?FC??_CHECK_CRC16X_?CRC16
FCODE 008234H 000013H INSECTION ?FC??PUTCHAR?MAIN
008247H 007DB9H *** GAP ***
FCODE 010000H 00000DH AT PR?MAIN?MAIN
01000DH 00FFD3H *** GAP ***
FCODE 01FFE0H 000024H AT _crc_seg_

As you can see, the function Main is placed at 0x10000 which is correct. Examining the file main.lst gives us the assembly code for the main function

; FUNCTION main (BEGIN)
; SOURCE LINE # 14
10000 AE0000 F LDW X,#HIGH(?STR?MAIN?BASE)
10003 8D000000 F DNF CALLF ?printf
; SOURCE LINE # 15
10007 8D000000 F CALLF ?_check_crc16x_
1000B ?WHILE_0001:
; SOURCE LINE # 16
1000B 20FE JRA ?WHILE_0001

; FUNCTION main (END)

The first opcode is 0xAE,

Now, let's take a look at the HEX file. At line 2057 we have these lines:

:09FFF70000000000000000000001
:020000040001F9
:0D000000AE813E8D0080BF8D00814C20FE42
:0400000006000000F6
:10000D00000000002CC9FC015455505F5A30300AD5

As you can clearly see on the third line, it looks like it starts with the opcode for the main function. It looks fine. However, the fourth line adds data to the SAME ADDRESS as the third line. The data 06 00 00 00 is added to address 0x10000. So loading the HEX-file will not work at all.

Now, if we change the linker options to this : CRCRANGE(0x8000, 0x1FFD0), we can see that the output of the hexfile, from line 2057, looks like this

:09FFF70000000000000000000001
:020000040001F9
:0D000000AE813E8D0080BF8D00814C20FE42
:10000D00000000002CC9DF015455505F5A30300AF2

This looks fine! The offending line is not present. This hexfile can safely be loaded and executed.

BR
Andreas Hansson

PS.
If i remove the "at 0x10000" entry in the main.c file I get this error

OMF to HEX/BIN converter V4.04.11.201
Copyright (c) Raisonance S.A.S. 1987-2011. All rights reserved.
GENERATING EXTENDED HEX FILE: C:\SRC\TEST4\APPLICATION0.HEX
*** FATAL ERROR: INCONSISTENT OBJECT FILE