topic Re: mc9s12xdt512 & paged - unpaged ram memory in S12 / MagniV Microcontrollers

mc9s12xdt512 & paged - unpaged ram memory

Eric_t — Wed, 27 Jan 2016 10:58:02 GMT

Hi,

I have a project that works with CW5.1 and mc9s12dg256 controller.

Now I have to migrate to mc9s12xdt512.

I have faced the following problem:

mc9s12dg256 has the RAM memory at address 0x1000 to 0x3FFF while the mc9s12xdt512 has the unpaged RAM at address 0x2000 to 0x3FFF.

As far as I know, RAM_FD uses the RAM segment of 0x1000..0x1FFF.

I have modified the linker of mc9s12xdt512 as follow:

RAM = READ_WRITE DATA_NEAR 0x1000 TO 0x3FFF;

Undefined all paged ram memory

//RAM_FB = READ_WRITE DATA_FAR 0xFB1000 TO 0xFB1FFF;

//RAM_FC = READ_WRITE DATA_FAR 0xFC1800 TO 0xFC1FFF;

//RAM_FD = READ_WRITE DATA_FAR 0xFD1000 TO 0xFD1FFF;

//PAGED_RAM INTO /* when using banked addressing for variable data, make sure to specify

// the option -D__FAR_DATA on the compiler command line */

// RAM_FB, /*RAM_FC, RAM_FD*/;

The project has been successfully migrated to mc9s12xdt512. It works properly without problems.

Now I have to use the paged ram memory.

I have modify the linker as follow:

RAM = READ_WRITE DATA_NEAR 0x1000 TO 0x3FFF;

/* paged RAM: 0x1000 TO 0x1FFF; addressed through RPAGE */

RAM_FB = READ_WRITE DATA_FAR 0xFB1000 TO 0xFB1FFF;

RAM_FC = READ_WRITE DATA_FAR 0xFC1800 TO 0xFC1FFF;

//RAM_FD = READ_WRITE DATA_FAR 0xFD1000 TO 0xFD1FFF;

PAGED_RAM INTO /* when using banked addressing for variable data, make sure to specify

the option -D__FAR_DATA on the compiler command line */

RAM_FB, RAM_FC/*, RAM_FD*/;

Also I have add the option -D__FAR_DATA on the compiler command line.

Unfortunately the project does not run. Somewhere in Init.c of Start12.c the controller crashes.

Does anyone know if there is anything else on linker and on compiler that I should modify?

Thank you in advanced.

Below is the full linker:

/* This is a linker parameter file for the MC9S12XDT512 */

This file is setup to use the HCS12X core only.

If you plan to also use the XGATE in your project, best create a new project with the

'New Project Wizard' (File|New... menu in the CodeWarrior IDE) and choose the appropriate

project parameters.

NAMES

/* CodeWarrior will pass all the needed files to the linker by command line. But here you may add your additional files */

END

SEGMENTS /* here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. All addresses are 'logical' */

/* Register space */

/* IO_SEG = PAGED 0x0000 TO 0x07FF; intentionally not defined */

/* non-paged EEPROM */

//EEPROM = READ_ONLY DATA_NEAR IBCC_NEAR 0x0C00 TO 0x0FFB;

/* non-paged RAM */

//RAM = READ_WRITE DATA_NEAR 0x2000 TO 0x3FFF;

RAM = READ_WRITE DATA_NEAR 0x1000 TO 0x3E2D;//0x1000 TO 0x3E3E;

NO_INIT_RAM = NO_INIT DATA_NEAR 0x3E2E TO 0x3FFD;//0x3E3F TO 0x3FFD;

NO_INIT_COMMON_RAM = NO_INIT DATA_NEAR 0x3FFE TO 0x3FFF;

/* non-banked FLASH */

//ROM_4000 = READ_ONLY DATA_NEAR IBCC_NEAR 0x4000 TO 0x7FFF;

//ROM_C000 = READ_ONLY DATA_NEAR IBCC_NEAR 0xC000 TO 0xFEFF;

ROM_C000 = READ_ONLY DATA_NEAR IBCC_NEAR 0xC042 TO 0xF2FF;

/* VECTORS = READ_ONLY 0xFF00 TO 0xFFFF; intentionally not defined: used for VECTOR commands below */

//OSVECTORS = READ_ONLY 0xFF10 TO 0xFFFF; /* OSEK interrupt vectors (use your vector.o) */

/* paged EEPROM 0x0800 TO 0x0BFF; addressed through EPAGE */

//EEPROM_FC = READ_ONLY DATA_FAR IBCC_FAR 0xFC0800 TO 0xFC0BFF;

//EEPROM_FD = READ_ONLY DATA_FAR IBCC_FAR 0xFD0800 TO 0xFD0BFF;

//EEPROM_FE = READ_ONLY DATA_FAR IBCC_FAR 0xFE0800 TO 0xFE0BFF;

/* EEPROM_FF = READ_ONLY 0xFF0800 TO 0xFF0BFF; intentionally not defined: equivalent to EEPROM */

/* paged RAM: 0x1000 TO 0x1FFF; addressed through RPAGE */

RAM_FB = READ_WRITE DATA_FAR 0xFB1000 TO 0xFB1FFF;

RAM_FC = READ_WRITE DATA_FAR 0xFC1800 TO 0xFC1FFF;

//RAM_FD = READ_WRITE DATA_FAR 0xFD1000 TO 0xFD1FFF;

/* RAM_FE = READ_WRITE 0xFE1000 TO 0xFE1FFF; intentionally not defined: equivalent to RAM: 0x2000..0x2FFF */

/* RAM_FF = READ_WRITE 0xFF1000 TO 0xFF1FFF; intentionally not defined: equivalent to RAM: 0x3000..0x3FFF */

/* paged FLASH: 0x8000 TO 0xBFFF; addressed through PPAGE */

PAGE_E0 = READ_ONLY DATA_FAR IBCC_FAR 0xE08000 TO 0xE0BFFD; //fonts

PAGE_E1 = READ_ONLY DATA_FAR IBCC_FAR 0xE18000 TO 0xE1BFFD;

PAGE_E2 = READ_ONLY DATA_FAR IBCC_FAR 0xE28000 TO 0xE2BFFD;

PAGE_E3 = READ_ONLY DATA_FAR IBCC_FAR 0xE38000 TO 0xE3BFFD;

PAGE_E4 = READ_ONLY DATA_FAR IBCC_FAR 0xE48000 TO 0xE4BFFD;

PAGE_E5 = READ_ONLY DATA_FAR IBCC_FAR 0xE58000 TO 0xE5BFFD;

PAGE_E6 = READ_ONLY DATA_FAR IBCC_FAR 0xE68000 TO 0xE6BFFD;

PAGE_E7 = READ_ONLY DATA_FAR IBCC_FAR 0xE78000 TO 0xE7BFFD;

PAGE_E8 = READ_ONLY DATA_FAR IBCC_FAR 0xE88000 TO 0xE8BFFD;

PAGE_E9 = READ_ONLY DATA_FAR IBCC_FAR 0xE98000 TO 0xE9BFFD;

PAGE_EA = READ_ONLY DATA_FAR IBCC_FAR 0xEA8000 TO 0xEABFFD;

PAGE_EB = READ_ONLY DATA_FAR IBCC_FAR 0xEB8000 TO 0xEBBFFD;

PAGE_EC = READ_ONLY DATA_FAR IBCC_FAR 0xEC8000 TO 0xECBFFD;

PAGE_ED = READ_ONLY DATA_FAR IBCC_FAR 0xED8000 TO 0xEDBFFD;

PAGE_EE = READ_ONLY DATA_FAR IBCC_FAR 0xEE8000 TO 0xEEBFFD;

PAGE_EF = READ_ONLY DATA_FAR IBCC_FAR 0xEF8000 TO 0xEFBFFD;

PAGE_F0 = READ_ONLY DATA_FAR IBCC_FAR 0xF08000 TO 0xF0BFFD;

PAGE_F1 = READ_ONLY DATA_FAR IBCC_FAR 0xF18000 TO 0xF1BFFD;

PAGE_F2 = READ_ONLY DATA_FAR IBCC_FAR 0xF28000 TO 0xF2BFFD;

PAGE_F3 = READ_ONLY DATA_FAR IBCC_FAR 0xF38000 TO 0xF3BFFD;

PAGE_F4 = READ_ONLY DATA_FAR IBCC_FAR 0xF48000 TO 0xF4BFFD;

PAGE_F5 = READ_ONLY DATA_FAR IBCC_FAR 0xF58000 TO 0xF5BFFD;

PAGE_F6 = READ_ONLY DATA_FAR IBCC_FAR 0xF68000 TO 0xF6BFFD;

PAGE_F7 = READ_ONLY DATA_FAR IBCC_FAR 0xF78000 TO 0xF7BFFD;

PAGE_F8 = READ_ONLY DATA_FAR IBCC_FAR 0xF88000 TO 0xF8BFFD;

PAGE_F9 = READ_ONLY DATA_FAR IBCC_FAR 0xF98000 TO 0xF9BFFD;

PAGE_FA = READ_ONLY DATA_FAR IBCC_FAR 0xFA8000 TO 0xFABFFD;

PAGE_FB = READ_ONLY DATA_FAR IBCC_FAR 0xFB8000 TO 0xFBBFFD;

PAGE_FC = READ_ONLY DATA_FAR IBCC_FAR 0xFC8000 TO 0xFCBFFD;

/* PAGE_FD = READ_ONLY 0xFD8000 TO 0xFDBFFF; intentionally not defined: equivalent to ROM_4000 */

//PAGE_FE = READ_ONLY DATA_FAR IBCC_FAR 0xFE8000 TO 0xFEBFFF;

/* PAGE_FF = READ_ONLY 0xFF8000 TO 0xFFBFFF; intentionally not defined: equivalent to ROM_C000 */

END

PLACEMENT /* here all predefined and user segments are placed into the SEGMENTS defined above. */

_PRESTART, /* Used in HIWARE format: jump to _Startup at the code start */

STARTUP, /* startup data structures */

ROM_VAR, /* constant variables */

STRINGS, /* string literals */

VIRTUAL_TABLE_SEGMENT, /* C++ virtual table segment */

//.ostext, /* eventually OSEK code */

NON_BANKED, /* runtime routines which must not be banked */

COPY /* copy down information: how to initialize variables */

/* in case you want to use ROM_4000 here as well, make sure

that all files (incl. library files) are compiled with the

option: -OnB=b */

INTO ROM_C000/*, ROM_4000*/;

DEFAULT_ROM,

CRC_ROM

INTO /*PAGE_FE,*/ PAGE_FC, PAGE_FB, PAGE_FA, PAGE_F9, PAGE_F8,

PAGE_F7, PAGE_F6, PAGE_F5, PAGE_F4, PAGE_F3, PAGE_F2, PAGE_F1, PAGE_F0,

PAGE_EF, PAGE_EE, PAGE_ED, PAGE_EC, PAGE_EB, PAGE_EA, PAGE_E9, PAGE_E8,

PAGE_E7, PAGE_E6, PAGE_E5, PAGE_E4, PAGE_E3, PAGE_E2, PAGE_E1, /*PAGE_E0*/;

//.stackstart, /* eventually used for OSEK kernel awareness: Main-Stack Start */

SSTACK, /* allocate stack first to avoid overwriting variables on overflow */

//.stackend, /* eventually used for OSEK kernel awareness: Main-Stack End */

DEFAULT_RAM /* all variables, the default RAM location */

INTO RAM;

NO_INTIALIZE_RAM INTO NO_INIT_RAM;

PAGED_RAM INTO /* when using banked addressing for variable data, make sure to specify

the option -D__FAR_DATA on the compiler command line */

RAM_FB, /*RAM_FC, RAM_FD*/;

//DISTRIBUTE DISTRIBUTE_INTO

// /*ROM_4000, *//*PAGE_FE,*/ PAGE_FC, PAGE_FB, PAGE_FA, PAGE_F9, PAGE_F8, PAGE_F7,

// PAGE_F6, PAGE_F5, PAGE_F4, PAGE_F3, PAGE_F2, PAGE_F1, PAGE_F0, PAGE_EF,

// PAGE_EE, PAGE_ED, PAGE_EC, PAGE_EB, PAGE_EA, PAGE_E9, PAGE_E8, PAGE_E7,

// PAGE_E6, PAGE_E5, PAGE_E4, PAGE_E3, PAGE_E2, PAGE_E1, PAGE_E0;

//CONST_DISTRIBUTE DISTRIBUTE_INTO

// /*ROM_4000,*/ /*PAGE_FE,*/ PAGE_FC, PAGE_FB, PAGE_FA, PAGE_F9, PAGE_F8, PAGE_F7,

// PAGE_F6, PAGE_F5, PAGE_F4, PAGE_F3, PAGE_F2, PAGE_F1, PAGE_F0, PAGE_EF,

// PAGE_EE, PAGE_ED, PAGE_EC, PAGE_EB, PAGE_EA, PAGE_E9, PAGE_E8, PAGE_E7,

// PAGE_E6, PAGE_E5, PAGE_E4, PAGE_E3, PAGE_E2, PAGE_E1, PAGE_E0;

//DATA_DISTRIBUTE DISTRIBUTE_INTO

// RAM, RAM_FD, /*RAM_FC,*/ RAM_FB;

//.vectors INTO OSVECTORS; /* OSEK vector table */

END

ENTRIES /* keep the following unreferenced variables */

/* OSEK: always allocate the vector table and all dependent objects */

//_vectab OsBuildNumber _OsOrtiStackStart _OsOrtiStart

END

STACKSIZE 0x500 /* size of the stack (will be allocated in DEFAULT_RAM) */

/* use these definitions in plane of the vector table ('vectors') above */

//VECTOR 0 _Startup /* reset vector: this is the default entry point for a C/C++ application. */

//VECTOR 0 Entry /* reset vector: this is the default entry point for an Assembly application. */

//INIT Entry /* for assembly applications: that this is as well the initialization entry point */

CHECKSUM

CHECKSUM_ENTRY METHOD_CRC16 OF READ_ONLY 0xC000 TO 0xFCBFFF INTO READ_ONLY 0xC020 SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xC042 TO 0xF3FF INTO READ_ONLY 0xC040 SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE08000 TO 0xE0BFFD INTO READ_ONLY 0xE0BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE18000 TO 0xE1BFFD INTO READ_ONLY 0xE1BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE28000 TO 0xE2BFFD INTO READ_ONLY 0xE2BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE38000 TO 0xE3BFFD INTO READ_ONLY 0xE3BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE48000 TO 0xE4BFFD INTO READ_ONLY 0xE4BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE58000 TO 0xE5BFFD INTO READ_ONLY 0xE5BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE68000 TO 0xE6BFFD INTO READ_ONLY 0xE6BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE78000 TO 0xE7BFFD INTO READ_ONLY 0xE7BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE88000 TO 0xE8BFFD INTO READ_ONLY 0xE8BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xE98000 TO 0xE9BFFD INTO READ_ONLY 0xE9BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xEA8000 TO 0xEABFFD INTO READ_ONLY 0xEABFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xEB8000 TO 0xEBBFFD INTO READ_ONLY 0xEBBFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xEC8000 TO 0xECBFFD INTO READ_ONLY 0xECBFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xED8000 TO 0xEDBFFD INTO READ_ONLY 0xEDBFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xEE8000 TO 0xEEBFFD INTO READ_ONLY 0xEEBFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xEF8000 TO 0xEFBFFD INTO READ_ONLY 0xEFBFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF08000 TO 0xF0BFFD INTO READ_ONLY 0xF0BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF18000 TO 0xF1BFFD INTO READ_ONLY 0xF1BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF28000 TO 0xF2BFFD INTO READ_ONLY 0xF2BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF38000 TO 0xF3BFFD INTO READ_ONLY 0xF3BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF48000 TO 0xF4BFFD INTO READ_ONLY 0xF4BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF58000 TO 0xF5BFFD INTO READ_ONLY 0xF5BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF68000 TO 0xF6BFFD INTO READ_ONLY 0xF6BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF78000 TO 0xF7BFFD INTO READ_ONLY 0xF7BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF88000 TO 0xF8BFFD INTO READ_ONLY 0xF8BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xF98000 TO 0xF9BFFD INTO READ_ONLY 0xF9BFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xFA8000 TO 0xFABFFD INTO READ_ONLY 0xFABFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xFB8000 TO 0xFBBFFD INTO READ_ONLY 0xFBBFFE SIZE 2 UNDEFINED 0xFF END

CHECKSUM_ENTRY METHOD_ADD OF READ_ONLY 0xFC8000 TO 0xFCBFFD INTO READ_ONLY 0xFCBFFE SIZE 2 UNDEFINED 0xFF END

END

HEXFILE BootloaderA_213_CRYSTAL_14745600_XDT512.s19

Re: mc9s12xdt512 & paged - unpaged ram memory

lama — Wed, 27 Jan 2016 18:23:20 GMT

Hi,

I am not sure you understand memory map well. Because of it I have attached a memory map I have prepared to better understand it.

Moreover, I have attached an example code related to addressing RAM.

Could you please look at attached files probably you will see what you are doing wrong? If this does not says you what to do please reply I will try to use another words and approach.

Best regards,

Ladislav

Re: mc9s12xdt512 & paged - unpaged ram memory

Eric_t — Thu, 28 Jan 2016 10:01:04 GMT

Hi Ladislav,

Thank you for your response.

I did not explain very well what I need. Sorry about that.

This is my problem:

I have a project with CW5.1 and mc9s12dg256 controller.

The controller has 12KB RAM (0x1000 to 0x3FFF) and the project uses almost the whole RAM area (it uses 11.5KB).

Now I have to migrate to mc9s12xdt512.

Unfortunately this controller has 8KB of unpaged RAM (0x2000 to 0x3FFF).

The firmware needs 11.5KB of unpaged RAM, so it cannot fit into xdt512 controller.

This link:mc9s12xdt256 & Paged RAM "https://community.freescale.com/thread/308499?q=paged" gave me the solution.

I have comment the paged ram and I have changed the unpaged RAM as 0x1000 to 0x3FFF.

With this approach the unpaged RAM of mc9s12xdt512 is identical to mc9s12dg256, so I can migrate to xdt512 easily.

The firmware works properly without problems.

Now I have a second problem:

I have to merge two project that originally written for mc9s12dg256 controller.

The first one uses 11.5KB of RAM and the second uses 1.8KB of RAM.

So merging the two project I need 11.5+1.8 = 13.3KB of unpaged RAM.

There is two possibilities:

-Modify the prm file in order to have linear 14KB of unpaged RAM.

This is the most preferable approach but I do not know if it can be done.

-modify the prm in order to have linear unpaged RAM of 0x1000 to 0x3FFF and paged RAM of "0xFB1000 to 0xFB1FFF" or "0xFC1000 to 0xFD1FFF" or "0xFD1000 to 0xFB1FFF".

Not so good, I have to modify the second project in order to work with paged RAM memory.

-use the default prm file (unpaged RAM 0x2000 to 0x3FFF)

This is the worst solution because the first project must be modified in order to work with paged RAM.

This is really painful because the first project is huge; it has 190 files.

Does anyone know if I can modify the prm file in order to have linear unpaged RAM of 14KB or at least linear 12KB unpaged RAM and 2KB of paged RAM?

Thank you in advanced.

Re: mc9s12xdt512 & paged - unpaged ram memory

lama — Thu, 28 Jan 2016 10:57:56 GMT

Hi,

could you please describe reason of linear RAM? Do you need it for one large array or is there another reason?

I will discuss the issue with my colleague and the variables type and requirement on placement can say more.

best regards,

Ladislav

Re: mc9s12xdt512 & paged - unpaged ram memory

lama — Thu, 28 Jan 2016 11:00:19 GMT

However, there is a possibility to R/W entire RAM space linearly if you use global addressing mod which uses assemble instruction global load, global store.

I can provide an example. Just wait a minute.

Best regards,

Ladislav

Re: mc9s12xdt512 & paged - unpaged ram memory

lama — Thu, 28 Jan 2016 12:02:21 GMT

Hi,

I think the approach I am presenting you in the attached example will help you to understand and will help you to solve your issue.

just look into prm file and search for keyword "//modified by LAMA" to see what I did to get 16kB linear address space which will be addressed by global address and 4kB short addressing mode space. I think this approach will help you if you use large linear arrays. the variables into the global address space have to use qualifier "far" to say the compiler that global addressing instruction will be used to address this variable. You can read something about global addressing instruction, which are used, in the S12XCPUV1 core reference manual.

( http://cache.nxp.com/files/microcontrollers/doc/ref_manual/S12XCPUV1.pdf )

best regards,

Ladislav

Re: mc9s12xdt512 & paged - unpaged ram memory

Eric_t — Thu, 28 Jan 2016 12:38:29 GMT

Hi Ladislav,

The reason for the linear RAM is that the first project uses a buffer of 7750 bytes, a stack of 1280 bytes and heap of 2048 bytes. All of them should be in unpaged RAM.

The second project uses a buffer of 1500 bytes and a stack of 256 bytes.

Since the project is huge (190 c files), moving the buffer of 7750 bytes to paged memory is really painful due to the length of the pointers; they have to be declared as far many many pointers of the project.

Actually I need unpaged RAM and not linear memory. For example, if I can have different unpaged RAM areas in order to fit the buffer of 7750 bytes, the stack, and the 1500 bytes of second project, I am OK.

The project that you have attached gives a way, but I need to make many change in the project. Can I force the CW to make all pointer 24bit instead of declaring *far?

Thank you in advanced.

Re: mc9s12xdt512 & paged - unpaged ram memory

lama — Thu, 28 Jan 2016 12:53:48 GMT

Hi,

I will ask a CW expert for help. The compiler manual, you can find in the pdf format in the instalation directory says:

LARGE Memory Model

The default large memory model supports both extended data and code. See the BANKED

Memory Model section for code-banking constraints. See the Paged Variables section for

data-paging support.

Because paged variables are not directly supported by the HC(S)12 instruction set, the

LARGE memory model has significant overhead compared with the SMALL or

BANKED memory models.

Note that __far functions and paged variables are possible in all memory models. If they

are not defaulted to by the memory model, the code is adapted to use these features. If only

a small part of the application actually needs paged variables, for example, then using a

smaller memory model and adapting the small model generates smaller and faster code.

However, in order to do not make a mistake it would be better if CW support expert helps in this question.

Best regards,

Ladislav

Re: mc9s12xdt512 & paged - unpaged ram memory

kef2 — Fri, 29 Jan 2016 09:03:19 GMT

Eric,

your prm mods are fine, I mean suppression and removal 0xFD1000 TO 0xFD1FFF from PLACEMENT. The only problem you should keep in mind is that you can't use (a little faster) R-page addressing, since you need to keep RPAGE=0xFD all the time to prevent mapping different R-page to 0x1000-0x1FFF address. The only option for you is to use global addressing to access paged RAM, which means you just need to allocate all paged RAM variables in __GPAGE_SEG section, make pointers to paged variables far, also if such paged variables are exported via header files, you need to place extern declarations also in __GPAGE_SEG section like below

in h file:

#pragma DATA_SEG __GPAGE_SEG PAGED_RAM

extern int mydata;

#pragma DATA_SEG DEFAULT

in c file

#pragma DATA_SEG __GPAGE_SEG PAGED_RAM

int mydata;

#pragma DATA_SEG DEFAULT

{

int * far ptr;

mydata = 1;

ptr = &mydata;

*ptr = 1;

}

Re: mc9s12xdt512 & paged - unpaged ram memory

Eric_t — Fri, 29 Jan 2016 11:42:23 GMT

Hi Enward,

I am a bit confused about how I should modify the prm file and the compiler command line.

I have the prm file as follow:

RAM = READ_WRITE DATA_NEAR 0x1000 TO 0x3FFF;

// paged RAM:

RAM_FB = READ_WRITE DATA_FAR 0xFB1000 TO 0xFB1FFF;

RAM_FC = READ_WRITE DATA_FAR 0xFC1000 TO 0xFC1FFF;

comment the RAM_FD page

//RAM_FD = READ_WRITE DATA_FAR 0xFD1000 TO 0xFD1FFF;

PAGED_RAM INTO /* when using banked addressing for variable data, make sure to specify

the option -D__FAR_DATA on the compiler command line */

RAM_FB, RAM_FC/*, RAM_FD*/;

Is that correct?

-D__FAR_DATA have to be placed on compiler command line?

Now I have the warning: L1128: Cutting value _Range beg from 0xFB1000 to 1000

Thank you in advanced

Re: mc9s12xdt512 & paged - unpaged ram memory

lama — Fri, 29 Jan 2016 11:56:48 GMT

Hi,

the solution suggested by Edward is OK. I know it but it is not very safe. You have really keep in mind that when you change the RPAGE then page FD is lost for your purpose. Moreover, all other space is good to be defined in the prm file as global space as I presented in the example project I sent to you.

So, if you want to use rpage addressing for FD and creat linear space 1000~3FFF then just remove pages and create global space for all other variables as I presented. However, you will need qualifier far for such a variables because near variables use 16 bit address and far variables 24 bit address.

I think the easiest appoach will be to "large" the project. Our CW expert will contact you after our discussion. The principle we want is to be all variables far in default.

Best regards,

Ladislav

Re: mc9s12xdt512 & paged - unpaged ram memory

kef2 — Fri, 29 Jan 2016 12:13:28 GMT

Hi Eric,

Yes, your changes are fine. Extend RAM segment to 0x1000 - 0x3FFF, commend RAM_FD and all references to RAM_FD in PRM (PLACEMENT and DATA_DISTRIBUTE ).

Yes -D__FAR_DATA has to be added to compiler command line once you start using paged RAM. This is required for proper operation of startup routine. Without __FAR_DATA defines, startup routine fails to initialize paged variables. I see the same message L1128 with -D__FAR_DATA removed from compiler settings. You certainly need it.

Ladislav,

the solution suggested by Edward is OK. I know it but it is not very safe. You have really keep in mind that when you change the RPAGE then page FD is lost for your purpose.

It is as unsafe as using banked memory for code storage. Single accidental write to PPAGE register and you are in weeds. Damage is no less worse than mapping different data to 0x1000-0x1FFF.

Regards,

Edward

Re: mc9s12xdt512 & paged - unpaged ram memory

trytohelp — Fri, 29 Jan 2016 16:41:34 GMT

Hi Eric,

It's difficult to know exactly what is your problem but it seems you want to have access to all memory without using far pointer.

Am I right ?

The Large memory model could be the solution but it's using more memory (code size) than Banked one.

You can create a project using this configuration using the wizard and selecting custom memory model.

Attached a zip file containing 2 projects.

In banked project the ptr_2 is not correctly evaluate because he should be define as far.

The same project using large memory model is working fine.

You can see the difference between banked and large memory model.

Don't know if this will help you.

Don't hesitate to contact us.

Have a great day,
Pascal
NXP Technical Support

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: mc9s12xdt512 & paged - unpaged ram memory

Eric_t — Mon, 01 Feb 2016 07:43:42 GMT

Hi Pascal,

The attached project cannot start. CW just shows the xml file.

Re: mc9s12xdt512 & paged - unpaged ram memory

trytohelp — Mon, 01 Feb 2016 08:02:52 GMT

You need to change the IDE config:

checking or un-checking the option Use Text-Based projects.

Save it, close and re-start the IDE.

Pascal

Re: mc9s12xdt512 & paged - unpaged ram memory

kef2 — Thu, 04 Feb 2016 08:05:50 GMT

Hi,

Indeed there's a problem with

RAM = READ_WRITE DATA_NEAR 0x1000 TO 0x3FFF;

and

-D__FAR_DATA

Without __FAR_DATA defined, startup.c fails initializing variables allocated in paged RAM. But when __FAR_DATA is defined, startup.c fails initializing non paged variables at 0x1000..0x1FFF (RPAGE=0xFD). Looks like compiler fails initializing _startupData struct in this case. It seems that 0x2000..0x3FFF address is properly converted to global 0xFE000'G.. 0xFFFFF'G when filling _startupData, while 0x1000..0x1FFF seems being treated as global 0x00000'G..0x00FFF'G .

Changing RAM segment line in PRM like below seems curing startup.c problem

RAM = READ_WRITE DATA_NEAR 0xFD000'G TO 0xFFFFF'G;

Edward