Manual Corrections and Updates for IAR Embedded Workbench for Renesas M32C

Manual Corrections and Updates for IAR Embedded Workbench for Renesas M32C V3.21A

Updated: 2007-10-01 [IMIB]
Archived: $Revision: 1.11 $

IAR C/C++ Compiler Reference Guide
IAR Assembler Reference Guide
IAR Embedded Workbench User Guide
IAR C-SPY Hardware Debugger Systems User Guide

IAR C/C++ Compiler Reference Guide

C CALLING CONVENTION, page 108-109:
If the first parameter to be passed to a function is a pointer, A0 is used. Otherwise, the following registers are used:

Size	Register
1 byte	R0L
2 byte	R0
4 byte	R2R0

Other parameters than the first are passed on the stack.

A new command line processor option was added in version 3.20A for the M32C/9x series of CPU cores. Now available processor options are:
--cpu=0 M32C/8x (default)
--cpu=1 M16C/80
--cpu=2 M32C/9x

--no_path_in_file_macros
Use this option to exclude the path from the return value of the predefined preprocessor symbols __FILE__ and __BASE_FILE__. This option is not available in the IAR Embedded Workbench IDE.

--no_typedefs_in_diagnostics
Normally, when a type is mentioned in a message from the compiler, most commonly in a diagnostic message of some kind, the typedef names that were used in the original declaration are used whenever they make the resulting text shorter.

--no_wrap_diagnostics
By default, long lines in compiler diagnostic messages are broken into several lines to make the message easier to read. Use this option to disable line wrapping of diagnostic messages.

--omit_types
By default, the compiler includes type information about variables and functions in the object output. Use this option if you do not want the compiler to include this type information in the output. The object file will then only contain type information that is a part of a symbol’s name. This means that the linker cannot check symbol references for type correctness, which is useful when you build a library that should not contain type information.

--preinclude
Use this option to make the compiler include the specified include file before it starts to read the source file. This is useful if you want to change something in the source code for the entire application, for instance, if you want to define a new symbol.

--public_equ symbol[=value]
This option is equivalent to defining a label in assembler language by using the EQU directive and exporting it using the PUBLIC directive.

--preprocess[=[c][n][l]] {filename|directory}
Use this option to direct preprocessor output to a named file.

__root
The __root attribute can be used on either a function or a variable to ensure that, when the module containing the function or variable is linked, the function or variable is also included, whether or not it is referenced by the rest of the program.

By default only the part of the runtime library calling main and any interrupt vectors are root. All other functions and variables are included in the linked output only if they are referenced by the rest of the program.

The __root keyword is placed in front of the type, for example to place settings in non-volatile memory:

__root int settings[10];

The #pragma object_attribute directive can also be used. The following declaration is equivalent to the previous one:

#pragma object_attribute=__root
int settings[10];

Note: The __root keyword cannot be used in typedefs.

_Pragma
The preprocessor operator _Pragma can be used in defines and has the equivalent effect of the #pragma directive. The syntax is:

_Pragma("string")

where string follows the syntax for the corresponding #pragma directive. For example:

#if NO_OPTIMIZE
#define NOOPT _Pragma("optimize=2")
#else
#define NOOPT
#endif

Variadic macros
Variadic macros are the preprocessor macro equivalent to printf style functions. Syntax:

#define P(...) __VA_ARGS__
#define P(x,y,...) x + y + __VA_ARGS__

Here, __VA_ARGS__ will contain all variadic arguments concatenated, including the separating commas. Example:

#if DEBUG
#define DEBUG_TRACE(...) printf(S,__VA_ARGS__)
#else
#define DEBUG_TRACE(...)
#endif
...
DEBUG_TRACE("The value is:%d\n",value);

will result in:

printf("The value is:%d\n",value);

#pragma required
Use the #pragma required directive to ensure that a symbol which is needed by another symbol is present in the linked output. The symbol can be any statically linked function or variable, and the pragma directive must be placed immediately before a symbol definition. Use the directive if the requirement for a symbol is not otherwise visible in the application, for example, if a variable is only referenced indirectly through the segment it resides in.
Example:
void * const myvar_entry @ "MYSEG" = &myvar;
...
#pragma required=myvar_entry
long myvar;

#pragma segment
The #pragma segment directive declares a segment name that can be used by the intrinsic functions __segment_begin and __segment_end.
Example:
#pragma segment="MYSEG"

__segment_begin and __segment_end
Returns the address of the first byte of/first byte after the named segment. The named segment must be a string literal that has been declared earlier with the #pragma segment directive.
Example:
#pragma segment="MYSEG"
...
segment_start_address = __segment_begin("MYSEG");
segment_end_address = __segment_end("MYSEG");

__func__
The macro __func__ expands into a string with the function name as context if used inside a function body.
Example:
printf("%s\n",__func__);

--migration_preprocessor_extensions
Migration preprocessor extensions extend the preprocessor in order to ease migration of code from earlier IAR compilers. The preprocessor extensions include:
- The availability of floating point in preprocessor expressions.
- The availability of basic type names and sizeof in preprocessor expressions.
- The availability of all symbol names (including typedefs and variables) in preprocessor expressions.

If you need to migrate code from an earlier IAR C or C/EC++ compiler, you may want to enable these preprocessor extensions. Note: If you use this option, not only will the compiler accept code that is not standard conformant, but it will also reject some code that does conform to standard.

Important! Do not depend on these extensions in newly written code. Support for them may be removed in future compiler versions.

Runtime library, page 24.
Additional DLIB libraries has been added to reflect the two library configurations Normal and Full. The information on page 24 should be changed accordingly. The names of the libraries are constructed in the following way:
<type><cpu_variant><memory_model><float_size><library_configuration>.r48

where
- type is cl for the IAR CLIB runtime environment and dl for the IAR DLIB runtime environment
- cpu_variant is m32c80 or m32c
- memory_model is one of n or f or h for near, far and huge memory model, respectively
- float_size is d for 64 bit and blank for 32 bit.
- library_configuraton is one of n or f for normal and full, respectively (only on DLIB).

Segment reference - Heap segments in the DLIB runtime environment
In the DLIB library environment it is possible to allocate memory for heaps placed in different memories. By default the standard library functions malloc, free etc., as well as the C++ new operator allocates memory in the heap that corresponds to the memory model, as descibed in the table below.

To allocate data in a specific memory you can in C use variants of the standard function with the memory attribute prefixed, e.g. __near_malloc. In C++, the memory type attribute can be specified for example using new __near.

Memory type	Segment name	Memory attribute	Used by default in memory model
Near	HEAP	__near	Near
Far	FAR_HEAP	__far	Far
Huge	HUGE_HEAP	__huge	Huge

See the IAR Runtime Environment and Library User Guide for information about how to set the size for each heap.

IAR Assembler Reference Guide

Assembler options, page 3.
The command line options -b and -d have been removed in assembler front-end as there is no need for them anymore. Instead of using the -b option, the module control directive .module shall be used.

IAR Embedded Workbench User Guide

None

IAR C-SPY Hardware Debugger Systems User Guide

PC7501 and Compact Emulator debugger system, chapter "Using the emulator" -> "Hardware setup"

Memory map
This area shows the available memory of the selected device. When single chip or memory extension mode has been selected, this area shows the automatically allocated internal ROM address range.

Debug monitor bank address
The debugger allocates a 64-Kbyte continuous address area as the emulator's work area for use by the debug monitor. Specify any bank that the target system does not use. The debug monitor uses a 64-Kbyte area from the start address of the specified bank. (Example: If the specified bank is 0xF0, then the debug monitor uses a 64-Kbyte area beginning with address 0xF000000.)

The following limitations apply:

The bank specified here cannot have its contents referenced or set. The contents of this area might be incorrectly displayed in the Memory window or the Program/Source window’s disassembly display mode.
MCU internal resources (e.g., SFR and RAM areas) cannot be used as a bank address.
The DRAM area and a multiplexed area can not be used as a bank address.
The interrupt vector area can not be used as a bank address.

Emulation Memory Allocation
When Memory Expansion Mode or Microprocessor Mode has been selected, emulation memory can be allocated to the extended area to be debugged (in up to four areas). Here, allocate memory for the debug target area and specify its mapping information.

Bank
(Set bank address) Specify the bank address of the debug target area to be allocated in hexadecimal notation. If specified as C0, 0xC00000 is the start address of the debug target area.

Length
(Specify the size of area) Specify the size of the debug target area (256 bytes or 1 Mbytes). If Length is specified to be 256 bytes, banks 00, 04, 08, and up to FC (every four banks) are specified as Bank; if Length is specified to be 1 Mbytes, banks 00, 10, 20, and up to F0 (every 16 banks) are specified as Bank.

Map
(Specify the area map)

Specify the mapping information (Internal or External) for the specified area. If no area is specified, select No Use.

Internal: The area specified to be "Internal" is mapped into the internal area (emulation memory).

External: The area specified to be "External" is mapped into the external area (external resources in the target system).

Areas for which No Use is selected as Map and those not specified here, are mapped to external areas. Compared to the case where areas are explicitly specified to be External, the only difference is the download speed. (Downloading into these areas is slower than downloading to the areas specified to be External.)

The internal ROM area is automatically mapped to the emulation memory. Therefore, there is no need to set it here.

Be careful that the debug areas do not overlap.

Make sure that the total size of the specified debug target areas does not exceed the emulation memory size of the emulation probe. The size of emulation memory that can be allocated varies with each emulation probe. (Consult the user’s manual of your emulation probe.)

The setting of the emulation memory area varies depending on the specified processor mode.

Single chip Mode
You do not need to specify the area to be assigned as the emulation memory. The internal ROM area is automatically mapped to the emulation memory. The address range of the automatically mapped area is displayed in the Internal ROM Area field.

Memory Expansion Mode (8bit and 16bit)
If you have an area to be assigned as the emulation memory in addition to internal ROM area, specify it separately. The internal ROM area is automatically mapped to the emulation memory. The address range of the automatically mapped area is displayed in the Internal ROM Area field.

Microprocessor Mode (8bit and 16bit)
Specify the area to be assigned separately. (There is no area which is automatically assigned.)