Simplified migration to IAR Embedded Workbench

How to migrate to IAR Embedded Workbench as the development toolchain for Renesas processors

IAR Systems has a strong partnership with Renesas and we have been working together since the early nineties, at that time starting with NEC, Hitachi and Mitsubishi. Many of our customers use Renesas microprocessors, and many still move between different development tools for different architectures. IAR Embedded Workbench supports all Renesas architectures in a common platform, which means you can basically use one and the same environment for all Renesas microcontrollers. You get coverage for about ten families in the same toolset and you can even mix projects for different families within a common workspace.

This article will take a look at what to consider when migrating projects from Renesas development environment to IAR Embedded Workbench. There are tools available to simplify this, but there are still some basic coding differences that are good to be aware of when transferring a project.

Consider starting fresh

The first question you should ask yourself is: Do I need to migrate all existing code, or can I start with an example project and modify that? Within IAR Embedded Workbench, there are ready-made example projects for most of Renesas’ boards. These projects include for example the hardware setup of the different peripherals.  An option is to use an example project as the base, and then piece by piece move your old code. A list of currently supported Renesas kits is found at

Another option to start fresh is Renesas Applilet device driver generator. Applilet is a free tool that provides a GUI setup of peripherals, and generates an IAR Embedded Workbench project with device setup and a stub for your application. A great thing with this tool is that you can go back to it and re-generate code without overwriting your own code. This makes it easier to change the device but keep most of the code. If you are already using Applilet today, you actually only need to change project format (toolchain) from Renesas to IAR Embedded Workbench to be up and running.

Migration guides

Migration guides that describe how to port existing Renesas High-performance Embedded Workshop (HEW) and Renesas e2studio projects are available with IAR Embedded Workbench. On a detailed level, the guides describe differences in the tools and how to proceed to migrate. Project file conversion is explained step-by-step and important option settings are explicitly shown with screenshots. The guides also include a reference part providing side-by-side descriptions of tool options, keywords, #pragmas, etc. In case you need to port assembler code, the guides also describe calling conventions and assembler directives.

Project conversion

To port existing Renesas HEW or Renesas e2studio applications to IAR Embedded Workbench for RX there is a tool called Renesas to IAR project converter. This is a GUI application included with IAR Embedded Workbench, available via the Tools menu.


Figure 1: Renesas to IAR project converter

Renesas to IAR project converter creates an IAR Embedded Workbench project file, using a Renesas HEW or Renesas e2studio project file for RX as input. You browse to the original Renesas project file and information like file groups, source file names, defined symbols, include paths, build configurations, exclude-from-build, is automatically transferred to a new IAR Embedded Workbench project. Optionally, this tool also excludes Renesas-specific setup files and makes source code text substitutions like exchanging keywords and rewriting interrupt declarations. Conversion hints for the user are presented as#pragma error messages.

Basic code differences

In this chapter, we will look at some of the basic differences between code written for Renesas tools and IAR Embedded Workbench. This information is also available in the migration guides.

Initialization code

The Renesas HEW/e2studio project generator creates the startup code as seen in table 1, while the IAR Embedded Workbench startup code is part of the runtime library. By including the cstartup assembler source file in the project, the startup code in the runtime library is overridden. Cstartup makes a call to a function called __low_level_init() and if it is available in your source code, you can use it for example to initialize hardware.


Note that you shall normally not port the files resetprg.c, dbsct.c, intprg.c and vecttbl.c at all as the corresponding setup is already covered by cstartup. Instead, you should focus on the HardwareSetup() function.

Memory mapping

For Renesas HEW and e2studio, you either configure you memory in the GUI or in a so called sub command file. In IAR Embedded Workbench, you select the device in the Project Options, and automatically get the memory setup to match the on-chip memory of the selected microcontroller. If you have external memory, you edit the linker configuration file and store it with your IAR Embedded Workbench project.

Interrupt declarations

There is a difference between the toolchains in how to declare interrupts. While Renesas tools use #pragma interrupt, IAR Embedded Workbench uses the __interrupt keyword and a #pragma to set the vector offset. The vector symbol is defined in the SFR header file.

Inline assembler

To declare inline assembler functions, Renesas tools use a #pragma while IAR Embedded Workbench uses the asm keyword.


Table 2: Declaration of inline assembler functions

SFR I/O files

Using HEW or e2studio, the SFR header files are created by the project generator and stored with the project. IAR Embedded Workbench has one SFR header file per device family. These are stored in the product installation tree and the include path for the SFR header files is known by IAR Embedded Workbench.

IAR Embedded Workbench actually uses SFR files from Renesas. There are at least two big advantages with this; 1) it ensures that the SFR definitions correspond to the latest hardware manual revision and 2) it is significantly easier to port source code between toolchains when the SFR naming is identical.

Renesas ABI compliance

For RX, SH and RH850, IAR Embedded Workbench follows the so called Renesas ABI. An ABI is a specification for calling conventions, data types, sizes, alignments, stack frame organization, etc. Thanks to the Renesas ABI, you can link a library built with Renesas or any other tool following the ABI, together with your application. This opens up for code re-use between toolchains and can also save test time.


Renesas Peripheral Driver Library (RPDL)

An example of code re-use between toolchains is the Renesas Peripheral Driver Library (RPDL). The RPDL is an API for controlling the peripherals on your microcontroller. With the RPDL, you can use the peripherals without knowing the exact details about them. Instead, look in the library reference to find the suitable API call.

Eclipse support as an option

You can use IAR Embedded Workbench for Renesas targets together with Eclipse. Use Eclipse either under a plain installation or under Renesas e2studio where plugins for IAR Embedded Workbench are included by default. The hardware debuggers of e2studio can read the output from IAR Embedded Workbench, which means that the debug environment is also shared.

This article is written by Micael Borgefeldt, Product Manager at IAR Systems.

© IAR Systems 1995-2016 - All rights reserved.