Please note:
I originally thought linker script was the cause of this issue, further debugging indicates it is actually a case of the debugger not writing the _mdata region of Flash under some circumstances.
I am trying to locate some variables in the Data Flash region of my Rx processor.
I have added the following section to linker script for GNU compiler.
MEMORY
{
RAM : ORIGIN = 0x4, LENGTH = 524284
RAMSB : ORIGIN = 0x000A4000, LENGTH = 8192
DFLASH : ORIGIN = 0x00100000, LENGTH = 32768
RAM2 : ORIGIN = 0x00800000, LENGTH = 524288
OFS : ORIGIN = 0xFE7F5D00, LENGTH = 128
ROM : ORIGIN = 0xFFE00000, LENGTH = 2097512
}
.dflash (NOLOAD) :
__DFlash_Start = .;
KEEP(*(.dflash.01))
KEEP(*(.dflash.02))
KEEP(*(.dflash.03))
KEEP(*(.dflash.04))
KEEP(*(.dflash.05))
KEEP(*(.dflash.06))
KEEP(*(.dflash.07))
KEEP(*(.dflash.08))
KEEP(*(.dflash.09))
KEEP(*(.dflash.10))
KEEP(*(.dflash.11))
KEEP(*(.dflash.12))
KEEP(*(.dflash.13))
KEEP(*(.dflash.14))
KEEP(*(.dflash.15))
KEEP(*(.dflash.16))
KEEP(*(.dflash.17))
KEEP(*(.dflash.18))
*(.dflash)
__DFlash_End = .;
} > DFLASH
Then the variables are allocation to each section as follows:
const Type_t dfType __attribute__((section(".dflash.01"))) __attribute__ ((aligned (64))); // 64 bytes allocated
This all works fine and the map file shows my variables as being located at the correct address.
The problem is that when I try to debug with the E2 debugger, the ROM location _mdata is not updated if the linker contains this dflash section.
This means that ram initialises with garbage and the application wont run.
If I comment out this section from the linker file, the mdata is correctly written to the mcu and my code will run.
Uncomment the section and compile, code will once again load and run as the _mdata section is now correct in the mcu.
Change the code so it is bigger or smaller, compile and debug and the _mdata in the mcu (as viewd through debugger) remains at the last running compile location, not wherever it now is located.
I have investigated the elf file and the correct data for the _mdata section is located at the correct address according to the map file.
However, when I try and debug, the code is loaded correctly and initialisation tries to read the data from the correct _mdata address but the data at this address is not correct as the debugger doesn't seem to have changed it from the last run.
If I add an expression which points to the last compiles _mdata location, I can see the correct data, so I know the old location values are being used. However, the elf file definitely contains the correct data at the correct new _mdata location.
I tried deleting the elf file to ensure no caching, setting the elf file location to absolute path. No matter what I do, the symptoms are that the code won't initialise the RAM correctly because the _mdata area in ROM is not matching the compiled _mdata location.
What version of GCC compiler you're using right now?
Hossein said:After all, try reading the binary file after programming (using Renesas Flash Programmer V3) then investigate it through a hex editor software (My choice is NeoHexEditor) to see if the _mdata contains the desired values.
Please try this and attach the .hex and Linker Script files. Also, it's better to insert your code in the forum through insert>code in the forum's chatbox (It's more readable). Thank you
GCC was version 8.3.0.202305-GNURX
I did an update check and this was latest. I updated all other e2 studio to latest versions.
I then rolled my code back to the failing version , did a clean and build
_mdata was still at 0x00000000ffec2924 and I loaded the file using the debugger.
This time when I used the memory browser to look at the location 0x00000000ffec2924 I found the flash was correctly initialised and the code ran.
Hopefully this means that the bug has been fixed in the updates.
Just out of interest I checked the changed files
GCC For Rensas Rx Build Support was 24.1.0.v20240109-1648 now 24.4.0.v20240409-1605
GCC For Rensas Rx Support Files was 24.1.0.v20231213-0451 now 24.4.0.v20240409-1133
Renesas Debug views was 9.4.0.v20231229-0313 now 9.5.0v20240402-1238
I certainly hope this update has fixed this as it has cost me a lot of time investigating the tool when I should have been debugging my own code.
Hello dear Bazza, Do you verify the problem is solved after updating the toolchain? Thanks for your update.
If this or any other user's response answers your concern, kindly verify the answer. Thank you!
Renesas Engineering Community Moderatorhttps://community.renesas.com/https://academy.renesas.com/en-support.renesas.com/.../