Monday April 22nd, 2019   Products, Targets   15 Comments

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)
    1. [Binutils][Bug Fix] Objdump decoded instructions as g14 specific instructions.
    2. [GCC][Bug Fix] Fixed the unexpected result generated when comparing to a global pointer.
    3. [Newlib][Improvementx] Updated to newlib version 3.1.0.
    4. [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)
    5. [Newlib][Improvement] Optimized string functions.
    6. [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.
  • GCC for Renesas 4.8.4.201902-GNURX (Windows | Linux)
    1. [Binutils][Bug-Fix] Fixed the objdump code generation for MOV, POP, PUSH
    2. [Binutils][Bug-Fix] Fixed the dissambly generation of NOP instructions
    3. [Binutils][Bug-Fix] Improved the opcode decoding for RXv3 instructions
    4. [GCC][Bug-Fix] Fixed the detection of SSTR string opcode.
    5. [GCC][Improvement] The rmpa builtin function can now accept byte/word/long access size and parameters.
    6. [GCC][Improvement] Implemented save and rstr as attributes.
    7. [GCC][Improvement] The -mtfu option is now supported. TFU builtin functions are now available.
    8. [GCC][Improvement] A warning is now generated when mvtipl is used with -mcpu=rx610
    9. [GCC][Bug-Fix] Fixed the bit set builtin fuctions atomic access.
    10. [GCC][Bug-Fix] Fixed the isinf_sign and isnan builtin functions bug generated due to the newlib update.
    11. [GCC][Improvement] Optimized the xchg builtin function.
    12. [GDB][Bug-Fix] Fixed the simulation of some RXv3 instructions.
    13. [Newlib][Improvement] Updated to newlib version 3.1.0
    14. [Newlib][Improvement] Nano libraries are now available
    15. [Newlib][Improvement] Optimized string library functions.
    16. [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“

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 Cam

15 Responses to The Renesas RX and RL78 Targets Get Updated Toolchains Today (Release 2019q2)

  1. andrepereira says:
    Monday October 14th, 2019 at 02:12 AM

    How do i integrate toolchain on e2studio ?

    • GNU Tools Support says:
      Monday October 14th, 2019 at 03:11 AM

      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”.

  2. andrepereira says:
    Sunday October 20th, 2019 at 06:29 AM

    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!

  3. andrepereira says:
    Tuesday October 22nd, 2019 at 03:47 AM

    Any news ?

  4. alice.trifu says:
    Tuesday October 22nd, 2019 at 04:31 PM

    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

  5. guravaiah.m@dtdsgp.com says:
    Saturday February 22nd, 2020 at 10:05 PM

    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’

    • Darius Galis says:
      Tuesday February 25th, 2020 at 03:08 PM

      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

  6. guravaiah.m@dtdsgp.com says:
    Saturday May 23rd, 2020 at 09:05 PM

    how to set all variables as volatile variables using gnurl78
    compiler options?

  7. guravaiah.m@dtdsgp.com says:
    Saturday May 23rd, 2020 at 09:15 PM

    how to set all variables default as type volatile using gnurl78 compiler options?

  8. guravaiah.m@dtdsgp.com says:
    Saturday May 23rd, 2020 at 09:25 PM

    how to set all variables default as type volatile in e2studio?

  9. guravaiah.m@dtdsgp.com says:
    Sunday May 24th, 2020 at 09:41 AM

    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?

    • Darius Galis says:
      Monday May 25th, 2020 at 06:10 PM

      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

      • guravaiah.m@dtdsgp.com says:
        Monday May 25th, 2020 at 08:23 PM

        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.

  10. guravaiah.m@dtdsgp.com says:
    Monday May 25th, 2020 at 08:48 PM

    the error might be due to vectors?

    can you help us?

    • Darius Galis says:
      Tuesday May 26th, 2020 at 12:18 PM

      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

Leave a Reply

Support