FreeRTOS RZ/A1 DS-5 GCC 14.01

qwedvit wrote on Wednesday, November 05, 2014:


I’ve been using the DS-5 platform for Eclipse to compile my projects to run on the RZ/A1.
So far, I’ve been using the sample software provided by Renesas to check if all the peripherals work as expected on my own protype board.
Next I want to take the development a little further, which means including FreeRTOS.
I’ve followed the steps that are mentioned in the README.txt.
Unfortunatly, when I open the project in the work environment, I get a ton of syntax errors.
The includes in the source file “syscalls.c” (such as #include <_ansi.h> , #include <stdio.h> , etc…) does not seem to be recognized.
I cannot find these files anywhere on my system.
These seem to be standard library files.
Is this because I’m working with the GnuCC 14.01 compiler instead of the mentioned 13.01?


rtel wrote on Wednesday, November 05, 2014:

Where did the project come from? The official FreeRTOS download has RZ demos for the IAR and ARM compilers, and there is also a separate contributed demo for GCC? there will be an official GCC demo for RZ very soon now there is a FreeRTOS GCC port for Cortex-A.


qwedvit wrote on Wednesday, November 05, 2014:

I’ve downloaded the FreeRTOS project from link below:
It’s the unofficial third party demo written for the RZ Embedded Processor (ARM Cortex-A9 core) with GCC development tools.
Do I need to wait for the official GCC demo, or could I just add the missing files from another resource?


rtel wrote on Wednesday, November 05, 2014:

I’ve not tried myself, but from the errors you report it looks like some
kind of library path issue as the libraries are part of the compiler,
and if the compiler is installed normally they should be found
automatically. I would suggest looking at the linker section of the
project options to ensure there are not absolute paths used.


qwedvit wrote on Wednesday, November 05, 2014:

All paths in the GCC linker have been set to relative. During compiling I get the message that the file “libFreeRTOS_Demo.a” could not be found.
I’ve searched my computer and this file is nowhere to be found, although there is a file called “”.
Has this too got something to do with these lirary paths?

rtel wrote on Wednesday, November 05, 2014:

That makes it sound like it is building FreeRTOS as a library. I’m not
sure why it does that, but if you can find the .map file then presumably
the library must have been built…somewhere.

When I get a chance I will open up the project and look, but I’m
currently on the road.


qwedvit wrote on Thursday, November 06, 2014:

I’ve started over again to make sure no paths were corrupted during the process…
The next steps were followed:
-Downloaded the zip file from (second link for RZ (ARM Cortex-A9))
-Unzipped this folder into C:
-Opened DS-5 and created a new workspace in 'C:\FreeRTOSV7.5.3_GNU_RSK+RZA1H\FreeRTOSV7.5.3’
-Imported existing project from: C:\FreeRTOSV7.5.3_GNU_RSK+RZA1H\FreeRTOSV7.5.3\FreeRTOS\Demo\CORTEX_A9_RZ_R7S72100_IAR_DS-5
-Went to project properties and under: C/C++ build -> settings changed toolchain version to v14.01
-Under: GCC C Compiler includes, added absolute path to arm directory of installed GNUARM v14.01 and removed the one referring to a non-existing directory v13.01
-Changed optimization level to none
-Under Build steps -> Post-build steps added the command: arm-rz-eabi-objcopy -O binary ${ProjName}.x ${ProjName}.bin& in order to get binary and motorola output.
After completing these steps, I tried to build the project once again.
The Eclipse console gives me the “Build Finished” line, although there are unresolved inclusions and errors.
But this time the libFreeRTOS_Demo.a file seems to be generated.
Hopefully this text aids in reproducing the same error.?

[EDIT]: I’ve included another absolute path to a directory of the GNU compiler. Turns out this was the main cause for the unresolved inclusions.
With #include “iodefine.h” the error: “symbol “NULL” couldn’t be resolved” is gone.
Am I messing anything up by including this file?
After this still some errors remain like “type size_t” couldn’t be resolved".

Thank you for your time

rtel wrote on Thursday, November 06, 2014:

I just downloaded and tried to compile the project. It compiled ok down
as far as syscalls.c, then complained it could not find swi.h. The
header file is in the compiler’s installation directory, but I noticed
the include paths in the project were hard coded to have the compiler in
c:/program files/KPIT, whereas on my computer they are in

Fixing that allowed me to compile the code, but when arm-rz-eabi-libgen
is invoked it just crashes, reporting “Error -1073741819”. It seems to
be building a project specific library, which it is using ‘FreeRTOS’ in
the name of because the project is called FreeRTOS_Demo - but I suspect
the library just contains the C run-time that will be used in the final
link step as the FreeRTOS code is built as part of the application - as
far as I can see anyway.

If you look in the libgen options (in the project options dialog) you
will see there is an option to use a pre-built library rather than
building the project specific one. My attempt to use that alternative
option would indicate that the library needs to be built at least once
first though.

I am however using the older compiler still and am out of the office
currently so can’t download the latest compiler.


qwedvit wrote on Friday, November 07, 2014:

The Project-Built library type with “Newlib” (standard GNU library) selected resulted in building the required libFreeRTOS_Demo.a library.
Next I’ve changed the library type to Pre-Built and changed the library to Optimized.
The compiler creates the binary files and is ready to flash.
However there still remain multiple errors as symbol ‘size_t’ could not be resolved.
Do you know which library contains the definition for the size_t type?
Maybe if I know the exact location, I can try to add this file manually?

[EDIT]: Additional information: The release notes of the GNUARM-RZ v14.01 mentions a known issue in ARM-RZ-EABI.

  1. While building the Newlib library using ‘libgen’ tool, many compiler warnings are generated by the ‘libgen’ tool. These warnings are displayed on ‘stdout’ while building the runtime libraries. These warnings are observed while building the pre-built libraries as well

Kind regards

qwedvit wrote on Thursday, November 13, 2014:

I’ve created a new workspace as the readme.txt tells me from ealier posted URL. Modified GNU compiler path program files to program files (x86). After this step it compiles the code succesfully, which means I’ve got a working copy!
But when opening the syscalls.c file a ton of errors and warnings appear.

In DS-5: go to window > preferences > C/C++ > Code Analysis. Turn off all potential programming problems and turn off all Syntax ans Semantic errors.

edwards3 wrote on Thursday, November 13, 2014:

In which case those are not compiler warnings, just interfering from an IDE that is not parsing the code properly. Lots of people complain about that, I don’t know why they have it switched on by default because it just causes confustion.