0

Example (in Renesas e2 studio 2023-01 and GCC_VERSION 8.3.0.202405-GNURX):

  1. File > New > C/C++ Project > Select “GGCC for Renesas RX C/C++ Executable Project” > Next
  2. Name project > Browse Location > Next
  3. Keep tool chain (8.3.0.202405) > Select device “R5F52317AxLA” > Change to “E2 (RX)” HWD > Next
  4. Skip Smart Configurator > Next
  5. Next
  6. Next
  7. Finish

Project template created…

In main source file:

  • Add some static volatile initiated variables just above the main function:

static volatile int Array[256] = {0x12345678};
static volatile unsigned int Probe = 0x11223344;

  • Use them in main:

while(1) {

// TODO: add application code here
if(0x12345678 != Array[0]){return(-1);}
if(0x11223344 != Probe){return(-1);}
}

  • Compile and run while it crashes before reaching main.
  • Now remove the initiation part of the variables:

static volatile int Array[256];// = {0x12345678};
static volatile unsigned int Probe;// = 0x11223344;

  • Compile and run successfully to main, although it then returns (-1) it is expected.

Any comments?

Best regards, Henrik

Open Source Tools Support answered
    • Hello,

      Thank you for reaching out to us!

      Unfortunately we are not able to reproduce the issue.

      In order to aid our investigation, please attach the full-built e2 Studio project for both of
      the mentioned cases. You may also share the code privately with us by opening a dedicated support ticket, where you can attach it.

      __
      Best regards,
      The Open Source Tools Team

    • Hello again : )

      This is odd, yesterday I created that sample project twice to ensure it really happened, and it did. Today it will not happen. Unfortunately, I deleted all the files in between as I easily replicated the problem (back then).

      As I recall, the problem was when the “jsr _HardwareSetup” vas taken, it jumped somewhere in the Exception table (just somewhere ahead) with the fatal rte.

      The real project amounts to nearly 2000 source files and still have this problem. What I can see, the initialized data transfers from flash works incorrectly. the size of .sdata is 8 bytes larger than the .idata and therefore it mis-alignes somewhere the near end.

      This happens only when .sdata ends on an even boundary, like 0x6000 so my work around is to put another int (dummy) in the .sdata section when it happens.

      Now, I suspects our linker script may be the culprit?
      Maybe someone with better knowledge can tell:

      8X – – – –

      SECTIONS /* * * Random Access Memory * * */
      {
      /* * * unique input sections first * * */
      .kernel (NOLOAD) : {*(.coredata)} > RAM
      .system (NOLOAD) : {*(.system)} > RAM
      .scode : AT(__icode) {. = ALIGN(4); __scode = .; *(.scode) . = ALIGN(4); __scode_next = .;} > RAM
      .ustack (NOLOAD) : {. = ALIGN(SYS_RANGE); *(.ustack)} > RAM
      .istack (NOLOAD) : {. = ALIGN(4); *(.istack)} > RAM
      /* * * zero-initiated data sections then * * */
      .sbss : {. = ALIGN(4); __gp = .; __sbss = .; *(.sbss.*) *(B) *(B_1) *(B_2) . = ALIGN(4); __sbss_next = .;} > RAM
      /* * * initiated data sections then * * */
      .sdata : AT(__idata) {. = ALIGN(4); __sdata = .; *(.sdata.*) *(D) *(D_1) *(D_2) . = ALIGN(4); __sdata_next = .;} > RAM
      /* * * versatile input sections last * * */
      .bss : {. = ALIGN(4); *(.bss) *(.bss.*) *(COMMON)} > RAM
      }

      SECTIONS /* * * Program Flash Memory * * */
      {
      /* * * unique input sections first * * */
      .cfm : {*(.rodata.cfm)} > APPL
      .stall : {*(.text.halt)} > APPL
      .reset : {*(.text.reset)} > APPL
      /* * * versatile input sections then * * */
      .text : {*(.text.*) *(C) *(C_1) *(C_2) *(P)} > APPL
      .rodata : {*(.rodata.*)} > APPL
      /* * * initiation data section last * * */
      .idata : {. = ALIGN(4); __idata = .; . += SIZEOF(.sdata);} > APPL
      .icode : {. = ALIGN(4); __icode = .; . += SIZEOF(.scode);} > APPL
      }
      – – – – X8

      Note: the RAM/APPL is defined in a device specific ld-file.

      Hopefully this was not too much of a wall of text…

      Thank you for your time
      /Hen