Installation script for Eclipse and GNU gcc based JLink Renesas RX toolchain

After my last post “How to set up an Eclipse and GNU gcc based toolchain to build and debug your Renesas RX based project on Linux”, I packed all the installation steps into one single script. The script downloads all the necessary sources, installs the needed dependencies, compiles all the sources and also downloads a copy of eclipse Kepler and installs all the necessary eclipse-CDT plugins.

After the installation all the files will be installed in the directory “/opt/rx-elf”. You might change the installation target directory in the script, but then the eclipse-example-workspace has to be adjusted.

The script also downloads an example for an eclipse-workspace which can be used out of the box with a Renesas RX GR-Sakura board and a JLink JTAG-Adapter.

This version is tested on a fresh install of Ubuntu 13.10:


Execute the script as follows (for a 32-bit architecture substitute the _amd64 suffix by _i386):

sudo sh install_rx-elf_toolchain_V1.0_UBUNTU_13.10_amd64 &> rx-elf.log

After the installation script is run, you only have to add the user who should work with the toolchain to the “jlink” group and copy the eclipse example workspace e.g. to your home directory.

sudo usermod -a -G jlink youruser
cp /opt/rx-elf/eclipse-rx-elf-example-workspace /home/youruser -r

Then you have to download the proprietary JLink-GDB server from the SEGGER-Homepage and extract all the files to /opt/rx-elf/JLink.

The eclipse IDE can be started by


Creative Commons License
rx-elf eclipse gcc toolchain installer by thwebel is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at

How to set up an Eclipse and GNU gcc based toolchain to build and debug your Renesas RX based project on Linux (part 3)

This is part 3 of how to set up your GNU gcc based toolchain for your Renesas RX project. In this article I will explain how to install the CDT plugin into Eclipse and how to set up the debugging that Eclipse will work with your J-Link GDB-server and your Renesas RX target.

The other parts are:

After part 2, you have a working gcc to compile a project and we can start our J-Link gdb server which connects to the target.

The next step is to download Eclipse. In this how-to I will use Eclipse Kepler. After extracting and starting Eclipse, you have to install the CDT plugin:

  • Under the help menu choose the point “Install new software”.
  • Add the repository
  • Choose the features (C/C++ Development Tools, C/C++ GCC Cross Compiler Support, C/C++ GDB Hardware Debugging, C/C++ Enhanced Memory View)
Eclipse install new software dialog

Eclipse install new software dialog

After installing the CDT plugin, you have to create a new project: Under File->New->Project, create a new C project. Choose the project type as Executable->Empty Project and for the toolchain choose “Cross GCC”.

In the next dialog you have to enter your cross compiler prefix. If you used the same prefix as I used in part 1, the prefix is “rx-elf-” and the cross compiler path is “/opt/rx-elf/bin”. After pressing the button to finish the dialog, you should end up with an empty project.

To make your first steps, you can again use Andrew Karpow’s GR-Sakura template, which I mentioned earlier in part 1. Just copy the “src”-folder and the file gr-sakura.ld into your project tree and try to build the project. In the console window, you should see the compiler output and that the build was finished. A new folder “Debug” should be in your project tree. After that, you should move the file “gr-sakura.ld” into this new “Debug” folder and tell the linker to use it. You can do this in Project->Properties in the Properties Dialog under C/C++ Build->Settings. Here in the tool settings for Cross GCC Linker, you should modify the command to “gcc -T gr-sakura.ld”. The flag “-T gr-sakura.ld” tells the linker to use this linker script. Since the linker command is executed inside the “Debug” directory inside your project tree, the linker script has to be located there.

Aditionally, in the tool settings for Cross GCC Linker under expert settings, you should modify the command line pattern from




which will produce a file with the .elf suffix as an output.

Eclipse Porject Settings Dialog

Eclipse Porject Settings Dialog

After applying the changes and closing the dialog you can verify your changes by rebuilding the project. After the rebuild, in the console output, you should see the executed linker command as follows:

rx-elf-gcc -T gr-sakura.ld  -o "test123".elf  ./src/blink.o

Additionally, after the build, a file with the .elf suffix should reside inside the Debug directory.

Now, we want to program the RX target and start our debugging. To do so, you have to create a new debug configuration, which you can do under the Menu Run->Debug Configurations. Here right click GDB Hardware Debugging and create a new configuration. In the main tab verify that the C/C++ Application field contains the .elf file, which is the result of the build process. In the tab debugger, you have to enter the name of the gdb, which is “rx-elf-gdb” if you used the prefix from part 1 when building the toolchain. The default port, the J-Link gdb server listens on, is port 2331. Do not forget to apply the changes before changing to the next tab.

In the startup tab for your debug configuration, uncheck the points “Reset and Delay” and “Halt” and enter the following commands into the text field for the initialization commands:

monitor flash breakpoints = 1
monitor flash device = R5F563NB
monitor flash download = 1
monitor reset
monitor halt

If you do not use the GR-Sakura board, you have to substitute the chip you are using in the second command. In the Load Image and Symbols field, the points “Load image” and “Load symbols” should be checked.

Apply the changes and close the dialog. Now you can start the J-Link GDB-server in a separate console window and start your debugging session. Go to Run->Debug Configurations, choose the new configuration you created in the last step under GDB Hardware Debugging and hit “Debug”. After this, Eclipse should look like this:

The Eclipse debugging perspective

The Eclipse debugging perspective

Congratulations! Now you can do hardware debugging on your target and find out, why the GR-Sakura template might not work as expected. But this is another story.

How to set up an Eclipse and GNU gcc based toolchain to build and debug your Renesas RX based project on Linux (part 2)

This is part 2 of how to set up your GNU gcc based toolchain for your Renesas RX project. In this article I will explain how to run your J-Link gdb server and how to connect your target to the J-Link (in my case I worked with the Gadget Renesas GR-Sakura board).

The other parts are:

After having a working compiler in the end of part 1, you can download the J-Link gdb-server included in the J-Link software & documentation pack for Linux from the SEGGER homepage.
To make the gdb-server work, you need to have libusb installed. Since the J-Link gdb-server also needs I had to create a symlink to the already installed in my /lib directory. If you already have a symlink or version 5 of libreadline installed, you can skip this step.

ln -s /lib/ /lib/

If you want to start the J-Link gdb-server as a normal user, you have have to make sure, the right permissions are set after plugging in the J-Link. First you need a group whose users should be able to start the server and your user has to be a member of the group.

groupadd jlink
usermod -a -G jlink youruser

After that, the following udev-rule written in a new file e.g. /etc/udev/rules.d/99-JLink.rules worked to set the right permissions for the J-Link:

ACTION!="add", SUBSYSTEM!="usb", GOTO="kcontrol_rules_end"
ATTRS{idProduct}=="0101", ATTRS{idVendor}=="1366", MODE="664", GROUP="jlink"

Note, that the files containing udev rules are applied in alphabetical order, so by naming it “99-foo.rules” you make sure no other predefined rule will apply after your own rule and overwrite it. Now after plugging in the J-Link you can try to start the J-Link gdb-server and it should look like this:

SEGGER J-Link GDB Server V4.62a

JLinkARM.dll V4.62a (DLL compiled Feb  6 2013 11:42:42)

The server has been started with the following settings:
---Server related settings---
GDBInit file:              none
Listening port:            2331
SWO thread listening port: 2332
Accept remote connection:  yes
Logfile:                   off
Verify download:           off
Init regs on start:        on
Silent mode:               off
Single run mode:           off
---J-Link related settings---
J-Link script:             none
Target interface:          JTAG
Host interface:            USB
Target endian:             little
Target interface speed:    1000kHz

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 14 2012 22:34:52
Hardware: V8.00
Feature(s): FlashBP, GDB
Checking target voltage...

If you can see this, then you have a complete rx-elf GNU gcc-toolchain including a gdb-server for hardware debugging via JTAG.

To connect your RX-target to the J-Link, you need an adapter from the 20-pin J-Link interface to the RX 14-pin header. If you don’t want to pay a relatively large amount of money for a PCB with more or less nothing on it, you can build your own adapter with the schematics below:

Schematic for the J-Link RX adapter.
Schematic for the J-Link RX adapter.

After connecting your target to the J-Link, the J-Link gdb-server output should continue with something similar to that

Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 8
JTAG ID: 0x1D005447 (RX)
Connected to target

Continue with part 3.

How to set up an Eclipse and GNU gcc based toolchain to build and debug your Renesas RX based project on Linux (part 1)

Since I spent many evenings on this topic, in this article I will explain all the steps it took me to set up my complete Renesas RX GNU gcc based toolchain on Linux. The JTAG-Debugger I use is a SEGGER J-Link and the debug target is the Gadget Renesas GR-Sakura board which runs with a RX63N-Controller.

The installation process was tested on a fresh Ubuntu 13.10 installation and the complete installation procedure can be downloaded here as a single script.

I split this how-to into three parts:

First of all I have to thank DJ Delorie who had a really good tutorial on how to build a GNU gcc toolchain on his site which helped me a lot. All the credits for this part of my tutorial should go to him. I only added a few things so you can copy all the commands to your comand line and it should work right out of the box.

The first step is to create a directory where you want to put all the sources necessary to build the toolchain. Set the variable SRCDIR to the directory where you want to store the source code and and PREFIX where you want the toolchain to be installed.

export SRCDIR=/usr/src/rx-elf-src
export PREFIX=/opt/rx-elf
mkdir $SRCDIR

Install all the required dependencies for the installation on a fresh UBuntu 13.10 installation.

apt-get -q -y install libgmp-dev libmpfr-dev libmpc-dev texinfo libncurses-dev openjdk-7-jre

After that, you have to download all the source tarballs for gcc, binutils, gdb and newlib.

cd /tmp

For me the above downloaded versions worked. The binutils version is only a snapshot and not a real release, but the latest major release binutils-2.23.2 found on the ftp-server did not build without errors.

Now you can extract the sources and start building the toolchain. As mentioned in the gcc build documentation, the tools should not be built inside the source directories, but in seperate ones.

First start building the binutils:

tar xvjf /tmp/binutils-2.23.52.tar.bz2
mkdir rx-binutils
cd $SRCDIR/rx-binutils
../binutils-2.23.52/configure --prefix=$PREFIX --target=rx-elf
make install

After that, you can compile gcc as far as it succeeds without newlib. The switch –disable-libssp is set because I got a build error while compiling libssp. For me the toolchain works without it.

tar xvjf /tmp/gcc-4.6.4.tar.bz2
mkdir rx-gcc
cd $SRCDIR/rx-gcc
../gcc-4.6.4/configure --prefix=$PREFIX --target=rx-elf --enable-languages=c --with-newlib --disable-libssp
make -k
make -k install

Now newlib can be built with the new rx-elf-gcc. You have to make sure to put $PREFIX/bin into our search path before running the build:

tar xvf /tmp/newlib-2.0.0.tar.gz
mkdir rx-newlib
cd $SRCDIR/rx-newlib
../newlib-2.0.0/configure --prefix=$PREFIX --target=rx-elf --enable-languages=c --with-newlib
ln -s $PREFIX/bin/rx-elf-gcc $PREFIX/bin/rx-elf-cc
export PATH=$PREFIX/bin/:$PATH
make install

After newlib is built, the rest of gcc can be built:

cd $SRCDIR/rx-gcc
make install

Finally you can build gdb:

tar xvjf /tmp/gdb-7.6.tar.bz2
mkdir rx-gdb
cd $SRCDIR/rx-gdb
../gdb-7.6/configure --prefix=$PREFIX --target=rx-elf
make install

After that, all the tools to compile your RX project are available, you can verify that your gcc is working with Andrew Karpow’s GR-Sakura template. Download all the files contained in his git repository, cd into the directory containing the downloaded files, make sure the directory where all your toolchain binaries are installed ($PREFIX/bin) is in your search path PATH variable and type “make” in the command-line. The template should compile without errors.

Continue with Part 2.

Nixie-Clock schematics and PCB-layout

As I said in the previous post, I now provide the Nixie-Clock schematics and the PCB layout. All the CAD work was done using the free gEDA-suite.

In the schematics each of the twelve pins of each tube is a part on its own. The part T411 means tube 4, pin 11.

All the gEDA CAD project files and the schematics can be downloaded within the archive I provide all the files under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit

As I also said in the last post, I had some issues with the design as I provide it here. If you want to rebuild the design or do your own design based on this one, you have the chance to correct the issues.

The main issue is that the 32 kHz crystal connected to the ATtiny84 cannot be used. It was intended to be used as a precision clock to count the time if no DCF77 signal can be received. But if the controller clock speed is 32 kHz, the process of shifting the display data into the shift-registers is so slow, that you can see the shifting on the tubes. A workaround in a new design would be to use latched shift-registers, where the data can be latched to the outputs of the shift-registers after the complete shifting process is already finished. Since the current design was built using ordinary shift-registers, I had to run the controller with its internal 8 MHz clock, so that the shifting process is not visible. Another and even better solution would be to use a controller which runs with a fast internal clock, but has a timer module which is clocked by the external 32 kHz precision crystal.

The problem with using the controller’s internal 8 Mhz oscillator is, that if the DCF77 time signal can no longer be received, the clock’s accuracy is very bad. So if you are somewhere outside (or inside europe) where you can’t receive the DCF77 signal at all, the clock might be not good for you. Since at my home I can receive the DCF signal, I did not implement a mechanism to set the time manually. If the time is received once via the DCF receiver, the time is set, even if the signal is lost afterwards (but then the accuracy is bad). There is a header where three buttons can be connected and be used to implement a functionality like setting the clock manually.

I think in a not-that-far-away-future project, I will make a complete redesign of the clock using a 32-bit ARM Cortex-M0 or M3 processor. It would be a great project to get in touch with a 32-bit architecture. The plan is to use more surface mount components to shrink the PCB and to include a LAN or WIFI module so the clock can make use of a or act as a time-server and to implement the ability to use the GPS time from an external GPS receiver.

Update (2013-05-06): 

Another solution to avoid the slow display output when using the 32 kHz crystal would be to use a MCU which runs on its own fast clock for a fast display update, but has the ability to clock a timer-peripheral with the external 32 kHz crystal to count the time.

Nixie Clock Hardware Assembly

Here are some pictures of the Nixie-Clock I built in 2011. All the process steps like cutting the PCB, etching, drilling and soldering were done at home.

The Nixie Clock is controlled by an ATMEL ATtiny84 MCU which decodes the time from the signal of an attached external DCF77 receiver and outputs the display data to some shift registers. The six display tubes are IN-12b Nixie tubes and the anode voltage of approximately 140V is generated by a step-up converter controlled by a MC34063 IC. The clock including the DCF77 receiver can be powered by a 12V plug power supply and draws less than 500mA.

I will publish the PCB layout, the schematics and the source code after I summarized all the problems and drawbacks I had after the assembly, because I cannot recommend it for an immediate rebuild.