Memory layout with memory.x

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Memory layout with memory.x

Post by Fred »

From the code :

Code: Select all

/* A description of what some of this means can be found at the following URL	*/
/* http://www.gnu.org/software/m68hc11/m68hc11_binutils.html					*/
/* http://m68hc11.serveftp.org/wiki/index.php/FAQ:Link							*/
The guts :

Code: Select all

  MEMORY
  {
/*    page0	(rwx)	: ORIGIN = 0x000000, LENGTH = 0x0000	This has been removed from the linker script as it is not relevant to the later core */
/*    eeprom (rx)	: ORIGIN = 0x000800, LENGTH = 0x0800 	 2K of eeprom for now, 4K requires paging */
    data	(rw)	: ORIGIN = 0x001000, LENGTH = 0x3000 /*	12K of ram for now, 32K requires paging */
    text1	(rx)	: ORIGIN = 0x004000, LENGTH = 0x4000 /*	Unpaged 4K flash block before page window */
    text	(rx)	: ORIGIN = 0x00C000, LENGTH = 0x3700 /*	Unpaged 4K flash block after page window minus serial monitor and vector space */

/*  Paged addresses = (((Value of PPAGE) * 0x4000) + 0x10000) */
    ppageE0	(rx)	: ORIGIN = 0x390000, LENGTH = 0x4000
    ppageE1	(rx)	: ORIGIN = 0x394000, LENGTH = 0x4000
    ppageE2	(rx)	: ORIGIN = 0x398000, LENGTH = 0x4000
    ppageE3	(rx)	: ORIGIN = 0x39C000, LENGTH = 0x4000
    ppageE4	(rx)	: ORIGIN = 0x3A0000, LENGTH = 0x4000
    ppageE5	(rx)	: ORIGIN = 0x3A4000, LENGTH = 0x4000
    ppageE6	(rx)	: ORIGIN = 0x3A8000, LENGTH = 0x4000
    ppageE7	(rx)	: ORIGIN = 0x3AC000, LENGTH = 0x4000
    ppageE8	(rx)	: ORIGIN = 0x3B0000, LENGTH = 0x4000
    ppageE9	(rx)	: ORIGIN = 0x3B4000, LENGTH = 0x4000
    ppageEA	(rx)	: ORIGIN = 0x3B8000, LENGTH = 0x4000
    ppageEB	(rx)	: ORIGIN = 0x3BC000, LENGTH = 0x4000
    ppageEC	(rx)	: ORIGIN = 0x3C0000, LENGTH = 0x4000
    ppageED	(rx)	: ORIGIN = 0x3C4000, LENGTH = 0x4000
    ppageEE	(rx)	: ORIGIN = 0x3C8000, LENGTH = 0x4000
    ppageEF	(rx)	: ORIGIN = 0x3CC000, LENGTH = 0x4000
    ppageF0	(rx)	: ORIGIN = 0x3D0000, LENGTH = 0x4000
    ppageF1	(rx)	: ORIGIN = 0x3D4000, LENGTH = 0x4000
    ppageF2	(rx)	: ORIGIN = 0x3D8000, LENGTH = 0x4000
    ppageF3	(rx)	: ORIGIN = 0x3DC000, LENGTH = 0x4000
    ppageF4	(rx)	: ORIGIN = 0x3E0000, LENGTH = 0x4000
    ppageF5	(rx)	: ORIGIN = 0x3E4000, LENGTH = 0x4000
    ppageF6	(rx)	: ORIGIN = 0x3E8000, LENGTH = 0x4000
    ppageF7	(rx)	: ORIGIN = 0x3EC000, LENGTH = 0x4000
    ppageF8	(rx)	: ORIGIN = 0x3F0000, LENGTH = 0x4000
    ppageF9	(rx)	: ORIGIN = 0x3F4000, LENGTH = 0x4000
    ppageFA	(rx)	: ORIGIN = 0x3F8000, LENGTH = 0x4000
    ppageFB	(rx)	: ORIGIN = 0x3FC000, LENGTH = 0x4000
    ppageFC	(rx)	: ORIGIN = 0x400000, LENGTH = 0x4000
    ppageFE	(rx)	: ORIGIN = 0x408000, LENGTH = 0x4000
/*  ppageFD	(rx)	: ORIGIN = 0x404000, LENGTH = 0x4000 Represents 0x4000 - 0x7FFF (text1 paged) */
/*  ppageFF	(rx)	: ORIGIN = 0x40C000, LENGTH = 0x3700 Represents 0xC000 - 0xFFFF (text paged) */
/*  The previous two lines are included for clarity only. */
/*	Changes to this file should be reflected in memory.h and Makefile also */
  }

  PROVIDE (_stack = 0x4000-1); /* Start the stack immediately after ram */
/*  PROVIDE (_vectors_addr = 0xFF00); I thought this was... : Where the linker puts the interrupt vectors. However apparently not. */
/* This is at 0xFF00 instead of 0xF700 because the monitor code redirects it, see AN2548 (also, the vector table on the 9s12x variants is twice as big...) */
at the bottom we have the location of the stack, immediately after the ram ends

page0 is traditionally where gcc puts interesting stuff for optimisation reasons, but, its a traditional thing with 8 bit stuff, not required for us, and I couldn't make it work for some reason.

I suspect the SM does not support the eeprom on our chip, but I could be wrong, or it could be an hcs12mem bug

btw, Flacid found that hcs12mem exists for windows too.

data is the ram area

text and text1 are unpaged flash NV memory

origin specifies the start point address in the memory map

and length is length :-)

if the address is longer than 4 digits i think, its treated as paged, the sm doc 2549? specs the formula for converting the addresses through.

each paged chunk can appear in the window if PPAGE is set appropriately. the PPAGE value to access those pages is in their name. you'll find the far calls for gcc to use in the memory.h file that correspond. near is not required, it is assumed to be the default if you don't spec far.

its complicated until you figure it out, then its dead simple. a bit of a black art for sure though.

i helped some dude on the gcc 68hc11 list the other day just by linking him to this file and msextra.com :-) (he had a c128)

does that help?

Admin.

ps, i havent really tried, but i havent had the paged stuff work yet. so the ppage ones may be wrong still. not sure.

and the p
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Memory layout with memory.x

Post by Fred »

Fred wrote:ps, i havent really tried, but i havent had the paged stuff work yet. so the ppage ones may be wrong still. not sure.
Yep, the ppage stuff was wrong. See 0.0.15 up for still untested, but potentially more correct ppage setup. At the least separate macros are required for data and functions. The original only had one set. "far" calls are only for functions, they don't apply to data storage linker instructions.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply