English
The Renesas RX and RL78 Targets Get Updated Toolchains Today (Release 2019q2)
The most popular Renesas targets, RX and RL78, are receiving updated toolchains today, for the first time this year. Both releases include an update to Newlib 3.1.0, and several additional improvements or bug-fixes.
The release notes for each of these platforms may be found below, covering what changes each of these new toolchain versions bring:
- GCC for Renesas 4.9.2.201902-GNURL78 (Windows | Linux)
- [Binutils][Bug Fix] Objdump decoded instructions as g14 specific instructions.
- [GCC][Bug Fix] Fixed the unexpected result generated when comparing to a global pointer.
- [Newlib][Improvementx] Updated to newlib version 3.1.0.
- [Newlib][Improvement] Nano libraries are now available. To use newlib-nano, users should provide additional gcc compile and link time option. –specs=nano.specs should be passed along with -specs=sim.specs if msim would be needed, else if msim is not needed -specs=lnosys.specs should be passed along with nano.specs. For example: $ rl78-elf-gcc test.c –specs=nano.specs -specs=sim.specs $(OTHER_OPTIONS)
- [Newlib][Improvement] Optimized string functions.
- [Newlib][Bug Fix] Added KEEP syntax for the frodata section into the default linker-script.
- Known issues
- ES is used without being initialized.
Workaround:
In order to initialize ES, the address should be stored in a far pointer before usage. So instead of:((volatile reg __far*)0x000FFF).bit._1 = 0;the code will be:
volatile reg __far *address0 = 0x000FFF;
(*address0).bit._1 = 0; - The __far keyword is not supported for C++ projects.
- ES is used without being initialized.
- GCC for Renesas 4.8.4.201902-GNURX (Windows | Linux)
- [Binutils][Bug-Fix] Fixed the objdump code generation for MOV, POP, PUSH
- [Binutils][Bug-Fix] Fixed the dissambly generation of NOP instructions
- [Binutils][Bug-Fix] Improved the opcode decoding for RXv3 instructions
- [GCC][Bug-Fix] Fixed the detection of SSTR string opcode.
- [GCC][Improvement] The rmpa builtin function can now accept byte/word/long access size and parameters.
- [GCC][Improvement] Implemented save and rstr as attributes.
- [GCC][Improvement] The -mtfu option is now supported. TFU builtin functions are now available.
- [GCC][Improvement] A warning is now generated when mvtipl is used with -mcpu=rx610
- [GCC][Bug-Fix] Fixed the bit set builtin fuctions atomic access.
- [GCC][Bug-Fix] Fixed the isinf_sign and isnan builtin functions bug generated due to the newlib update.
- [GCC][Improvement] Optimized the xchg builtin function.
- [GDB][Bug-Fix] Fixed the simulation of some RXv3 instructions.
- [Newlib][Improvement] Updated to newlib version 3.1.0
- [Newlib][Improvement] Nano libraries are now available
- [Newlib][Improvement] Optimized string library functions.
- [Newlib][Improvement] Optimized the sqrt function.
- Known issues
- In certain cases the program will time out while executing with following options:
(Note: Both flags need to be accompanied by “-fno-diagnostics-show-caret -w -O1 -DSTACK_SIZE=4096 -msim -lm” for the problem to be observed.)
a) -funroll-loops
b) -fpeel-loops - An incomplete type error can be observed ocasionally when using the -fpack-struct option in C++. The combination of the flags that reproduce this problem is “-fpack-struct -fno-diagnostics-show-caret -nostdinc++ -fmessagelength=0 -std=c++11 -pedantic-errors -Wno-long-long -S -msim“
- In certain cases the program will time out while executing with following options:
The Linux installer for both toolchains also offers command-line flags to automate installation as much as possible, as well as the ability to also act as an uninstaller for the toolchains. Therefore, the installer can both install and uninstall the toolchain from one or more paths from your Linux distribution. The release notes for both toolchains also include the list of the currently known issues presented above, to which we fully commit to adequately handle in the coming updates.
We are deeply grateful for any feedback you may have regarding this release, so please let us know if you have any questions or comments.
Sex Cam15 Responses to The Renesas RX and RL78 Targets Get Updated Toolchains Today (Release 2019q2)
コメントを残す
コメントを投稿するにはログインしてください。
How do i integrate toolchain on e2studio ?
You need to please install the toolchain first, then open up a recent version of e2Studio and the toolchain should be automatically detected. Just in case the automatic detection fails, you may also go to e2Studio and click the Help menu, then choose “Add Renesas Toolchains”.
I forgot to explain that I am using UBUNTU-MATE linux. I downloaded the gcc GNURL78.run and run the file, but when I go to the e2studio integration part, the toolchain file does not been reconized by defalt.
Is there a way to do that less paintfull ?
Thanks!
Any news ?
Hello,
Unfortunately, at this point, only the GNURX and ARM toolchains are supported by E2studio, on the Linux version, as you can see on Window → Preferences → Renesas → Renesas Toolchain Management.
In the near future, we will strongly advocate that support for GNURL78 toolchains to be added in E2studio for Linux.
Please let us know if we can help you with anything else.
__
Kind regards,
The GNU Tools Team
hi,
e2studio is not recognised __far keyword. using Renesas 4.9.2.201902-GNURL78 for windows.
getting build error.
example:
#define RADIO_FAR __far
void (RADIO_FAR *TxDone )( void );
can u please help me.
error: expected identifier or ‘(‘ before ‘__far’
Hello,
Unlike CCRL/IAR, the GCC RL78 doesn’t use the __far attribute for instructions that will be saved in the code section. In fact, in GCC this is not possible because the standard defines named address spaces only for data sections (please see the following: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf ).
In order to handle code bigger than 64 KB, GCC uses a PLT (Procedure Linkage Table) to achieve this feat. A good explanation about this can be found here:
https://www.technovelty.org/linux/plt-and-got-the-key-to-code-sharing-and-dynamic-libraries.html .
Although the article is about dynamic libraries, the same principle can be applied. Please observe the key part of the article:
“The indirection used here is called a procedure linkage table or PLT. Code does not call an external function directly, but only via a PLT stub. Let’s examine this…”
Please let us know if we can be of further assistance,
Best Regards,
The GNU Tools Team
how to set all variables as volatile variables using gnurl78
compiler options?
how to set all variables default as type volatile using gnurl78 compiler options?
how to set all variables default as type volatile in e2studio?
while hardware debugging getting error messages “NO SOURCE AVAILABLE FOR VECTORS() AT 0x” and “BREAK AT ADDRESS 0x NO DEBUF INFORMATION AVAILABLE”
and getting stuck at brk instruction.
how to get rid of this?
can I get help?
Hello,
Thank you for reaching out to us!
The “No source available” message is usually generated when the project is built without any debug information option enabled. We suggest checking the Project’s Debug Settings to be set at least as Debug level of -g2 and if the entry point is set correctly or the vector table is loaded at the correct address. If all those settings are correct, and the issue still persists we encourage you to open a private support ticket on our platform in which you can attach your project in order for us to investigate the issue more closely.
Regarding the volatile question, we would like to ask you for more details about what you are trying to achieve by disabling the optimization for every variable. The GCC compiler does not have an option that sets all variables as volatile, but it supports options that disable certain optimization passes. If you can provide us with some explanation about why you are needing this option, we might be able to offer more in-depth support.
We are looking forward to hearing from you,
The GNU Tools Team
Hi Darius Galis, Thank you for your accountability and improvise us.
we want to brief more about tool settings we follow.
debug level – g2
debug format -default
optimization -(Os)
vectors and device level settings given below
const unsigned char Option_Bytes[] __attribute__ ((section (“.option_bytes”))) = {
0x6EU, 0xFFU, 0xAAU, 0x84U
};
const unsigned char Security_Id[] __attribute__ ((section (“.security_id”))) = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};
#define VEC __attribute__ ((section (“.vec”)))
const void *HardwareVectors[] VEC = {
// Address 0x0
PowerON_Reset,
// Secure for Debugging
(void*)0xFFFF
};
#define VECT_SECT __attribute__ ((section (“.vects”)))
const void *Vectors[] VECT_SECT = {
// Address 0x4
R_Dummy, ////(void*)0xFFFF
// Address 0x6
R_Dummy,
// Address 0x8
INT_P0,
// Address 0xA
R_Dummy,
// Address 0xC
R_Dummy,
// Address 0xE
R_Dummy,
// Address 0x10
R_Dummy,
// Address 0x12
R_Dummy,
// Address 0x14
R_Dummy,
// Address 0x16
R_Dummy,
// Address 0x18
R_Dummy,
// Address 0x1A
R_Dummy,
// Address 0x1C
R_Dummy,
// Address 0x1E
R_Dummy,
// Address 0x20
INT_SR0,
// Address 0x22
INT_SRE0,
// Address 0x24
R_Dummy,
// Address 0x26
R_Dummy,
// Address 0x28
R_Dummy,
// Address 0x2A
R_Dummy,
// Address 0x2C
R_Dummy,
// Address 0x2E
R_Dummy,
// Address 0x30
R_Dummy,
// Address 0x32
INT_TM03,
// Address 0x34
R_Dummy,
// Address 0x36
INT_RTC,
// Address 0x38
R_Dummy,
// Address 0x3A
R_Dummy,
// Address 0x3C
R_Dummy,
// Address 0x3E
R_Dummy,
// Address 0x40
R_Dummy,
// Address 0x42
R_Dummy,
// Address 0x44
R_Dummy,
// Address 0x46
R_Dummy,
// Address 0x48
R_Dummy,
// Address 0x4A
R_Dummy,
// Address 0x4C
R_Dummy,
// Address 0x4E
R_Dummy,
// Address 0x50
R_Dummy,
// Address 0x52
R_Dummy,
// Address 0x54
R_Dummy,
// Address 0x56
R_Dummy,
// Address 0x58
R_Dummy,
// Address 0x5A
R_Dummy,
// Address 0x5C
R_Dummy,
// Address 0x5E
R_Dummy,
// Address 0x60
R_Dummy,
// Address 0x62
R_Dummy,
// Address 0x64
R_Dummy,
// Address 0x66
R_Dummy,
// Address 0x68
R_Dummy,
// Address 0x6A
R_Dummy,
// Address 0x6C
R_Dummy,
// Address 0x6E
R_Dummy,
// Address 0x70
R_Dummy,
// Address 0x72
R_Dummy,
// Address 0x74
R_Dummy,
// Address 0x76
R_Dummy,
// Address 0x78
R_Dummy,
// Address 0x7A
R_Dummy,
// Address 0x7C
R_Dummy,
// Address 0x7E
R_Dummy
};
while hardware debugging The ERROR MESSAGE is
Break at address “0xc7fc2” with no debug information available, or outside of program code.
the address is 0xc7fc2 is reserved memory where the brkl instructions are exist.
device memory range is 0x0000 to 0x1FFFF and F0000 to FFFFF.
device reserved memory is 0x20000 to 0xEFFFF
the device reserved memory is not supposed to be used for programming/debugging.
requesting you to please provide some advise on this.
Thanks.
the error might be due to vectors?
can you help us?
Hello,
Thank you for the quick answer.
While the information provided is useful, it doesn’t help getting to the root of the issue. This was the reason why we kindly asked you to open a private support ticket in which you should attach the ENTIRE e2studio project. It contains all the information needed to assess the generation of this undesirable behavior either through project-related configurations or specific code instructions (eg: vector table loading, not defining, at a wrong address).
Thank you for your understanding,
The GNU Tools Team