Output s-record for external memory

[MOEng]

I have some working code that supports an external EEPROM which is mapped in the PRM file with an address outside the range of the 9S12XS.  The starting address of this space is defined as 0x400000.

What I need to do is generate an s-record for this space.  The map file shows the variables allocated to this space, but I don't know if the abs file contains this space.   And if it does, how do I extract it using the burner file.

[kef]

You need to edit burner.bbl file, which should be already added to your project files tree, see Project Settings->Linker Files. Try adding these lines at top or at the bottom of your bbl file:

OPENFILE "%ABS_FILE%_ext_eeprom.s19"

format = motorola

busWidth = 1

SRECORD=Sx

len =    0x4000  

origin = 0x400000

destination = 0

SENDBYTE 1 "%ABS_FILE%"

CLOSE

[MOEng]

Thanks,

But this is what I tried initially.  All it generated was an S0 and S9 record.  I thought I was missing something but yours looks besically the same.

Here is what I used and the output.  Do you spot anything I missed?

Input from .bbl ->

OPENFILE "bin\External_EEPROM.s19"
format=motorola
busWidth=1
origin=0x400000
len=0x800
destination=0
SLINELEN=16
SRECORD=Sx
SENDBYTE 1 "%ABS_FILE%"
CLOSE

Ouput ->

S03D0000433A5C53616E64626F7865735C576F726B696E675C42617365446F6D65737469635F4253505C62696E5C42617365446F6D65737469632E616273AA
S9030000FC

I have used the burner file in the past on a project with an XDG using the internal EEPROM.  But this product is using the XS and the EEPROM is external.

All our manufacturing and field service tools use an s-record as an input.  So I need some way to get the initialization values out of the code.  Even if I could get a hex file, I could write (or find) a utility to generate an s-record.

[kef]

Probably your data is not referenced from the code and is optimised away by the linker. Either access data from the code or list it in ENTRIES section in your prm file.

[MOEng]

The file declaring variables for this memory space are already in the ENTRIES of the prm file because they do not get accessed directly.  They are accessed through a lookup table that contains the address and a tag.  So the linker would optimize them out if they were not in the prm file.

Thanks for your help, but it appears to me that this can't be done. 

I don't know for sure, but I don't think the linker really generates anything for the initialization values.

So even though I declare a variable in that segment as such;

#pragma CONST_SEG SOME_EEPROM_SPACE

const char data[3] = {1,2,3};

The linker may only generate an address for "data" but does nothing with the {1,2,3}.

[kef]

Certainly it can be done and is working. I tried it with empty project built for XS256. With your variant of bbl modification, I get data from 0x400000 put into S1 record with address 0000, as instructed (destination=0) in your bbl file. It's working. Make sure your data appears at 0x400000 in your map file.

[MOEng]

I must be completely missing something because I just created a project from scratch using the wizard and it did not work.  I zipped up the relevant files.  Maybe you can spot something wrong.

[kef]

MOEng, I also think that problem is NO_INIT instead of READ_ONLY.

But I don't understand something. S12XS doesn't have expanded memory, yet you have routine, which attemts to read access your external data directly. Is it a fake routine to force linker think data is used? If so, it may not work, unless you have -OnCstVar included in compiler command line switches, which is Disable CONST variable by constant replacement.

[MOEng]

Thank You,

The address and the NO_INIT were the issue.  I intended the address to be in the unimplemented EEPROM area so that the linker would genreate an address.  But the linker will actually generate an address of 0x400000 when as Daniel pointed out is not legit.  I need a logical to global review.

When I changed it to this, it worked.

    EXTERNAL_EEPROM = READ_ONLY 0x400800 TO 0x4008FF;

In files I attached previously I only included an access to that external memory to see if that was part of the issue.

If your interested I have attached a simplified but more complete explanation of the implementation.

[CompilerGuru]

The prm contains:

> EXTERNAL_EEPROM = NO_INIT 0x400000 TO 0x407FFF;

This snippet has 2 issues. First, and that the issue you are struggling with, the NO_INIT keyword tells the linker to drop all the initialization data.

If you want the content of the EXTERNAL_EEPROM to appear in the elf (and in the srecord), use READ_ONLY instead.

READ_ONLY as keyword is actually a bit unfortunate as it does not really mean that those areas cannot be written to. Instead for the linker it means that the data is initialized when downloading. So typically this is used for flash areas, but for debug in RAM setups it is not uncommon to use READ_ONLY areas in RAM.

The second issue is the address 0x400000. For the HC12 linker that's a paged address, with the page being bits 16..23 of the address (0x40) and the base address 0x0000, which is not a paged address usually.

I guess this is for the external address space? If so use 0x400000'G (global addressing) instead. I have to admit that I did not use that in the past (or now), so no experience from my side here.

So it should probably read:

> EXTERNAL_EEPROM = READONLY 0x400000'G TO 0x407FFF'G;

Daniel