Intel Hex binary with 23 bit addresses. How to? Help!

[mroczeks]

Hi All,

I am using CW 4.7 for my S12XEP100 MCU (onboard DEMO9S12XEP100).

I have a code wich starts at address 0x7FC000 (0xC000 local).

The rest of code (DEFAULT ROM) is placed in paged flash memory.

I need to generate Intel Hex file with 23 bit addresses. When all the code is placed in non paged memory (for example at 0xC000 local). The hex file contains entire code with 16 bit local addresses which I could deal with. But when some parts of code are placed in paged memory. The hex file contains local addresses only. In particular it contains addresses of non paged flash memory (I put there my startup routine) only. The code from paged memory is missing in the hex file.

I see that the '*.abs.glo' file I generate is OK. It has global (23 bit) addresses in each line.

But the '*.abs.s19' file has local (16 bit) addresses only included. The rest of code (the one placed in paged memory) is missing! And the hex file is probably generated using that s19 file (with local addresses only).

I need to find a way to generate hex files with 23 bit (global) addressing inside. Otherwise I will not be able to upload complete code to the MCU (via my own flash bootloader).

Please help,

Thanks

[Emac]

There are eight record types, listed below:

Record Description Address Bytes Data Sequence

S0	Block header	2	Yes
S1	Data sequence	2	Yes
S2	Data sequence	3	Yes
S3	Data sequence	4	Yes
S5	Record count	2	No
S7	End of block	4	No
S8	End of block	3	No
S9	End of block	2	No

The S0 record data sequence contains vendor specific data rather than program data.

The S2 fields describe the 24 bit location.  3 x 8 bit bytes = 24

See http://en.wikipedia.org/wiki/S19_(file_format)

format S2zzABCDEFyy...........yyzz

where S2 indicated the address size, zz indicates the number of bytes in the current Srecord line, yy.....yy is the data, and zz is the checksum of the line.   ABCDEF here is your 23 (aka 24) bit address.

[mroczeks · Accepted solution]

Hey guys!

Sorry for such a long silence.

I have been very busy doing my CAN flash bootloader for s12xep100...

That was what I needed that '23bit hex file' for.

I solved my problem some time ago.

Initially my .s19 file did only containt one S0 and one S9 record (which are non relevant vendor-specific headers) and several S1 records.

My .prm file was (I removed some parts of the file content below as not important for the topic):

SEGMENTS
    ROM_5000      = READ_ONLY     0x5000 TO   0x7FFF;

    PAGE_C0       = READ_ONLY   0xC08000 TO 0xC0BFFF;
    PAGE_C1       = READ_ONLY   0xC18000 TO 0xC1BFFF;
    PAGE_C2       = READ_ONLY   0xC28000 TO 0xC2BFFF;
    PAGE_C3       = READ_ONLY   0xC38000 TO 0xC3BFFF;
    PAGE_C4       = READ_ONLY   0xC48000 TO 0xC4BFFF;
    PAGE_C5       = READ_ONLY   0xC58000 TO 0xC5BFFF;
    PAGE_C6       = READ_ONLY   0xC68000 TO 0xC6BFFF;
    PAGE_C7       = READ_ONLY   0xC78000 TO 0xC7BFFF;
    PAGE_C8       = READ_ONLY   0xC88000 TO 0xC8BFFF;
    PAGE_C9       = READ_ONLY   0xC98000 TO 0xC9BFFF;
    PAGE_CA       = READ_ONLY   0xCA8000 TO 0xCABFFF;
    PAGE_CB       = READ_ONLY   0xCB8000 TO 0xCBBFFF;
    PAGE_CC       = READ_ONLY   0xCC8000 TO 0xCCBFFF;
    PAGE_CD       = READ_ONLY   0xCD8000 TO 0xCDBFFF;
    PAGE_CE       = READ_ONLY   0xCE8000 TO 0xCEBFFF;
    PAGE_CF       = READ_ONLY   0xCF8000 TO 0xCFBFFF;
    PAGE_D0       = READ_ONLY   0xD08000 TO 0xD0BFFF;
END

PLACEMENT
    _PRESTART, STARTUP, ROM_VAR, STRINGS, VIRTUAL_TABLE_SEGMENT, NON_BANKED, COPY
    INTO             ROM_5000;

    DEFAULT_ROM
    INTO             PAGE_C0, PAGE_C1, PAGE_C2, PAGE_C3, PAGE_C4, PAGE_C5, PAGE_C6,
                            PAGE_C7, PAGE_C8, PAGE_C9, PAGE_CA, PAGE_CB, PAGE_CC, PAGE_CD,
                            PAGE_CE, PAGE_CF, PAGE_D0;
END

As Emac wrote, S1 record contain 16 bit addressed data only which means it can only be usefull if your code is placed in nonpaged flash memory areas (this is the only memory area where you use 16 bit addressing).

So did my .hex file too. It only contained that 16bit addressed code data (00 data record type). The .s19 and .hex files content was identical, they both had only nonpaged memory parts of my application code.

Contrary, the .glo file did contain S1 record (for nonpaged memory) and S2 records (for paged memory areas).

To solve the issue, I changed my burner.bbl file. Inside that file there are two sections, the first describing generation of .glo file (containing global, 23bit addressing) and .s19 file (containing local, 16bit addressing).

I changed the .glo part of burner.bbl file from:

/* global s-record file */
OPENFILE "%ABS_FILE%.glo"
format = motorola
busWidth = 1
SRECORD=Sx

to:

/* global s-record file */

OPENFILE "%ABS_FILE%.hex"
format = intel
busWidth = 1
SRECORD=Sx

Now, after each build, I receive same .s19 file and a new .hex file instead of .glo file. The .glo file is not produced anymore (I did not need that anyway). The .hex file consist of proper intel hex formating with 32 bit capable addressing (04 extended linear address record - check http://en.wikipedia.org/wiki/Intel_HEX for intel hex file formating details).

[CompilerGuru]

How is that .abs.s19 generated? I guess with a *.bbl file which only maps the  unpaged ROM.

Can you show this bbl file? Typically I would expect the s19 to contain the banked code as well.

Daniel