HCX12 c lib & paged ram

[Eric_t]

Hello,
We are using cw 5.1 & mc9s12xdt512 controller
We have created a bank model project, and we recompiled the c lib so it can work with paged RAM.

We have done the following steps:
 -We have copied the lib project ({Install}\lib\hc12c\hc12_lib.mcp).
 -Open the file libdefs.h in an edit window.
 - We have set the macros LIBDEF_FAR_CONST_STRINGS, LIBDEF_FAR_STRINGS, LIBDEF_FAR_CONST_VOID_PTR, LIBDEF_FAR_VOID_PTR and LIBDEF_FAR_CONSTANTS to 1.
 -We define a brand new target for ansixbi.lib and change the name to _ansixbi.lib
 -We recompile the lib and we linked  the newly created library file to our application.

We have written the follow code the test the new lib:

#include <hidef.h> /* common defines and macros */
#include "derivative.h" /* derivative-specific definitions */

#include <string.h>
#include <stdio.h>

#pragma DATA_SEG __GPAGE_SEG PAGED_RAM
volatile unsigned long l_paged = 0xAABBCCDD; // paged var
#pragma DATA_SEG DEFAULT

volatile unsigned long l_non_paged, x; // non paged var

void main(void)
{
   (void) memcpy(&l_non_paged, &l_paged, sizeof(l_non_paged));
   for(;;)
   {
      x = l_paged;
      l_non_paged = x + l_paged;
   }
}

We have add -D__FAR_DATA in compiler command line

unfortunately, it does not work, the compiler gives the warning:
C1860: Pointer conversion: possible loss of data

l_paged is located to 0xFB000'G
l_non_paged is located to 0x2FD0

When the addresses of variables are passing to c lib, memcpy gets 0x10002F;G for l_paged and 0xD0FEC0'G for l_non_paged.

It looks as if the application is not aware that the new _ansixbi.lib waits for 24 addresses and feeds the lib with 16bit addresses

I have attached a small project and the recompiled lib

[lama]

Hi,

as I wrote before.

The easiest way is to open new project and copy all c and h files to it.

You will avoid all unexpected errors.

We have done it always in this way because there can anytime appear any new issue because libraries incompatibility.

Best regards,

Ladislav

[Eric_t]

I have found the problem.
I forgot to change the access paths to the local library.

Now the project is aware of the far ansi lib

However, the %s of sprintf is not working without casting

volatile unsigned char buff[20], model[4];

(void) sprintf(buff, "%s", /*(unsigned char *far)*/ model); // needs casting

I have attached a small project that demostate the problem.

[lama]

Hi,

Let me answer in general.

The message you got reports that the variable has different length of the address and the pointer was implicitly converted. If you want to have correct length I suggest you to step the code and check what is happening. The new project and copy/paste c and h files is faster than never ending solution of possible issues.

In this case, it could be probably enough to use explicit conversions. However, in these cases I suggest always to be sure you use correct addressing mode of processing selected by compiler. Probably recompiling of the files is not enough because NEAR/SMALL project has NEAR default placement of variables (up to 64B address) and FAR/BANKED project uses paged addressing/pointers as default. However all accesses can be explicitly handled by near/far modifiers.

I believe when you step the code you will see the issue of pointer usage and conversions.

BW, regarding pointers and functions like memcpy, memmove, I suggest to create own functions if you have uncompatible addresses. The system can use Global, RPAGE or near addressing modes so it is easy to get error.

These functions also uses “void” input parameter so I do not believe they are able to accept correctly input parameters of different formats.

From the CW…when you use project wizard…

Small memory model

The Small memory model is best suited if both the code and the data do fit into the 64 kB address space.

By default all variables and functions are accessed with 16 bit addresses. The compiler does support banked functions or paged variables in this memory model, however

all accesses have to be explicitly handled.

The small memory model should be used for all derivatives with less than 64k

Banked memory model

“The Banked memory model is using banked function calls by default. The default data access however is still 16 bit.

Because the overhead of the far function call is not very large, this memory model suits all applications with more than 64k code.

Data paging can be used in the banked memory model, however all far objects and pointers to them have to be specially declared.”

--------

You also will see my “far” modifiers to be sure the variable is correctly compiled.

In order to change memory model from near to banked I always suggest to create a new project for given model because there can be any issues which we are not able to locate.

I have attached examples of RAM addressing for XDT and one for XP. The XEP is a different family but principle of addressing is the same. The example shows how to use RAM linearly by GPAGE instructions. (look also into prm file)

Best regards,

Ladislav