C164, CA step CAN

Ciao Hannes,
you are mixing a lot of confused ideas...

1) Your reference source should ever be THE MANUALS - Keil for Software, Infineon for Hardware.
2) I repeat, you told me that you have an application that works when placed in RAM, so FORGET the errata sheet (temporarily..), if your application is working in RAM, it is UNLIKELY you are running into errata sheet problems!

About Mapping: basically any microcontroller has two main memory spaces: ROM and RAM; ROM will contain the NONVOLATILE program
part (CODE and CONSTants), while RAM will contain the DATA.
Going into further detail, each of these spaces can be divided into logical sections, each of them having some characteristics, defined by the "environment", where for "environment" i mean the Compiler Architecture and the Microcontroller Architecture and Instruction Set.
During Compiler Specification phase, the Compiler writer (Mr. Keil) studies the Microcontroller Instruction Set and decides how to best use it to obtain the "optimum" code during compile.
In case of C164, the ROM memory area is split into CODE and CONST classes, then the CODE class is further divided into NCODE (NEAR CODE) and FCODE (FAR CODE).
NEAR CODE means that code uses NEAR CALLS and NEAR RETURN of C164 Instruction Set, these are instructions that use only 16bit displacement and thus works only INSIDE of the SAME 64K memory segment.
If you need to call or jump to code contained into a different 64K segment, you must use FAR CODE, using FAR CALLS and FAR RETURN, which are instructions that use 24 bit displacement.
This same situation occurs for CONST classes: NCONST is a class the compiler accesses by means of a single preset DPP register, so it can be at most 16K wide.
If you need more CONSTants, you must place them in FCONST or HCONST sections.
The compiler generates different instruction sequences to access the different sections, this way you can choose to place some CONSTants into a small section that can be accessed very quicly and some other in a larger section that can be accessed slower.
If you are "crazy" enough (or if you know what you do, in some special case...), you can decide by yourself where to place each piece of code you write, like

void far MyFarFunction (void) ....

or

unsigned int huge MyHugeVariable;

otherwise Keil provides some preset memory models, like SMALL, MEDIUM, LARGE and so on.
Each memory model defines what memory classes the compiler will use, for instance the SMALL memory model will generate NEAR CODE (NCODE), NEAR CONSTant (NCONST) and NEAR DATA (NDATA) classes, while the LARGE model will generate FAR CODE and so on...
There are some exceptions, but I think that my explanation is near enough to reality to give you a 'basic' knowledge, please study the Keil manuals to get a more precise
description.

For MAPPING and MAP file, please start here.

http://www.keil.com/support/man/docs/l166/l166_memory.htm

Back to your application: when you debug a program in RAM, you place all sections (CODE, CONST, DATA) in RAM and this is an easy environment, you can mix everything and don't worry about non writeable memory spaces.
When you burn the program in ROM, you must redefine the MAPPING, this means you must precisely tell the linker where to put each memory class, paying attention to WRITEABLE and NON WRITEABLE memory.
If you place a DATA section into the ROM, you won't ever be able to WRITE to this section and your program will produce unpredictable results (C164 will go in the forest...)
When you burn a program in ROM, you must follow these steps:

1) decide the PHYSICAL C164 MEMORY LAYOUT - This means define what memory you will have in your system and where is placed into the address space.
When you debug a program in RAM, the RAM chip select is ENABLED by the monitor in a window starting at address 0x000000; this MUST be changed when you place a program in ROM, the RAM cannot be present at 0x000000.

2) Modify the STARTUP FILE to properly enable the memory (Chip Selects) in order to obtain the choosen layout at RunTime.

3) Properly LOCATE the memory SECTIONS and CLASSES at the correct RAM and ROM addresses.
You can use the simulator to check your configuration and to test if this will work before you burn an OTP.

Ciao
Bruno

Ciao Hannes,
you are mixing a lot of confused ideas...

1) Your reference source should ever be THE MANUALS - Keil for Software, Infineon for Hardware.
2) I repeat, you told me that you have an application that works when placed in RAM, so FORGET the errata sheet (temporarily..), if your application is working in RAM, it is UNLIKELY you are running into errata sheet problems!

About Mapping: basically any microcontroller has two main memory spaces: ROM and RAM; ROM will contain the NONVOLATILE program
part (CODE and CONSTants), while RAM will contain the DATA.
Going into further detail, each of these spaces can be divided into logical sections, each of them having some characteristics, defined by the "environment", where for "environment" i mean the Compiler Architecture and the Microcontroller Architecture and Instruction Set.
During Compiler Specification phase, the Compiler writer (Mr. Keil) studies the Microcontroller Instruction Set and decides how to best use it to obtain the "optimum" code during compile.
In case of C164, the ROM memory area is split into CODE and CONST classes, then the CODE class is further divided into NCODE (NEAR CODE) and FCODE (FAR CODE).
NEAR CODE means that code uses NEAR CALLS and NEAR RETURN of C164 Instruction Set, these are instructions that use only 16bit displacement and thus works only INSIDE of the SAME 64K memory segment.
If you need to call or jump to code contained into a different 64K segment, you must use FAR CODE, using FAR CALLS and FAR RETURN, which are instructions that use 24 bit displacement.
This same situation occurs for CONST classes: NCONST is a class the compiler accesses by means of a single preset DPP register, so it can be at most 16K wide.
If you need more CONSTants, you must place them in FCONST or HCONST sections.
The compiler generates different instruction sequences to access the different sections, this way you can choose to place some CONSTants into a small section that can be accessed very quicly and some other in a larger section that can be accessed slower.
If you are "crazy" enough (or if you know what you do, in some special case...), you can decide by yourself where to place each piece of code you write, like

void far MyFarFunction (void) ....

or

unsigned int huge MyHugeVariable;

otherwise Keil provides some preset memory models, like SMALL, MEDIUM, LARGE and so on.
Each memory model defines what memory classes the compiler will use, for instance the SMALL memory model will generate NEAR CODE (NCODE), NEAR CONSTant (NCONST) and NEAR DATA (NDATA) classes, while the LARGE model will generate FAR CODE and so on...
There are some exceptions, but I think that my explanation is near enough to reality to give you a 'basic' knowledge, please study the Keil manuals to get a more precise
description.

For MAPPING and MAP file, please start here.

http://www.keil.com/support/man/docs/l166/l166_memory.htm

Back to your application: when you debug a program in RAM, you place all sections (CODE, CONST, DATA) in RAM and this is an easy environment, you can mix everything and don't worry about non writeable memory spaces.
When you burn the program in ROM, you must redefine the MAPPING, this means you must precisely tell the linker where to put each memory class, paying attention to WRITEABLE and NON WRITEABLE memory.
If you place a DATA section into the ROM, you won't ever be able to WRITE to this section and your program will produce unpredictable results (C164 will go in the forest...)
When you burn a program in ROM, you must follow these steps:

1) decide the PHYSICAL C164 MEMORY LAYOUT - This means define what memory you will have in your system and where is placed into the address space.
When you debug a program in RAM, the RAM chip select is ENABLED by the monitor in a window starting at address 0x000000; this MUST be changed when you place a program in ROM, the RAM cannot be present at 0x000000.

2) Modify the STARTUP FILE to properly enable the memory (Chip Selects) in order to obtain the choosen layout at RunTime.

3) Properly LOCATE the memory SECTIONS and CLASSES at the correct RAM and ROM addresses.
You can use the simulator to check your configuration and to test if this will work before you burn an OTP.

Ciao
Bruno