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.
Hello dear Bazza, thank you for posting on the Renesas community.
The problem with your linker script is the 'NOLOAD' option, which you've assigned to the 'dflash' section, According to the GCC's user manual NOLOAD option is used when we want to exclude the value assignments when generating the binary file. although with that it will be included in map file, and memory assignment is done by the compiler.
So that you can read the value that resides in that memory section, but it won't get updated by programming.
I hypothesize that you've compiled and programmed the code one time without the (NOLOAD) option, and the values have been written in the ROM that time, but after adding the NOLOAD option, you always get the first variable assignment. and it has nothing to do with the elf file or the freshness of the binary file. (Your programmer will only erase the memory sections that your binary contains, That's why the values are not being cleared)
remove the NOLOAD option, and it should work.
I hope you find it useful, keep me posted about the result.
Best regards,Hossein.
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/.../
Thanks for the response.
The values which are not being updated are nothing to do with the DFLASH section I have defined, I don't want anything uploaded for the DFLASH, hence I think NOLOAD is actually correct.
The section which is not being updated is the ROM section initialisation data. The ROM area should have the application written to it, plus the initialisation data for RAM. This is defined as _mdata in the linker file and the "C" initialisation code copies the block of memory at "_mdata" to the RAM block between _data and _edata in order to initialise the RAM ready for the application to run.
This section of the linker script
.data : AT(_mdata)
_data = .; /* create a global symbol at data start */
*(.data) /* all .data sections in all files */
*(.data.*) /* all .data* sections in all files */
*(D)
*(D_1)
*(D_2)
_edata = .; /* define a global symbol at data end */
} > RAM
.tors :
__CTOR_LIST__ = .;
. = ALIGN(2);
___ctors = .;
*(.ctors)
___ctors_end = .;
__CTOR_END__ = .;
__DTOR_LIST__ = .;
___dtors = .;
*(.dtors)
___dtors_end = .;
__DTOR_END__ = .;
_mdata = .;
_mdata2 = .;
} > ROM
However, when I assign anything to the DFLASH section, the _mdata ROM area is not written to by the debugger.
Analysing the ELF file shows it has has the correct values at the _mdata address.
The initialisation code is pointing to the correct _data, _edata and _mdata locations.
However, when I start the debug session, the ROM at _mdata isn't updated.
This means the RAM becomes initialised with garbage and not the correct data.
The new section I have added should be completely independent of the ROM.
I have tried the .dflash area as both NOLOAD and without, no difference.
And on Friday I completely removed the dflash sectio, commented out any assignments cleand and rebuilt and it still didn't update the _mdata area.
This is an example of the _mdata without the NOLOAD
The pclk_speed should be 60000000.
I now seem to have it correctly initialising the _mdata area of ROM.
I need to now verify why this should make a difference, however, I enabled the Garbage collection of unused input sections and my map file still has the data flash sections I have defined, the memory usage correctly shows me how much data flash I have used and most importantly my code runs again.
Thank you for your update,
Have you solved your problem now? I don't think the garbage collection option can have this effect. could you please share the complete Linker script file? RXV3 core uses 'SMOVF' instruction to transfer the data. and if the binary file has the correct data in _mdata there should be no interference with other sections, If there is an issue, it might be due to something wrong with linker variables or messing up the LMA and VMA in the script file.
I'll be happy to know more about the root cause of the issue in detail. Regards.
The full Linker script is attached.
I agree with what you are saying in principal, but the reality it is not the case.
Currently in my last 10 attempts 100% turning off the garbage collection fails, 100% with garbage collection works. I think I need the garbage collection anyway due to Azure RTOS inflating the code size, but that's a separate matter. Really both should work the same, the fact they don't means I have a work around, but there is still an underlying issue.
I have observed that the code itself sometimes fails when I completely remove my dflash sections, this has had me going in circles because I commented out all my changes and it still failed. Then I put back and it fails, then suddenly it works and I don't know what has really changed. The only thing that has 100% reliably initialised the _mdata section of the Flash is the garbage collection. The rest of the linker script is what was auto generated by the smart configurator.
This to me indicates that the debugger sometimes does not correctly interpret what it needs to load to Flash and it fails to write the _mdata location. I even tried unchecking the overwrite checkbox to flash and found that the _mdata Flash was then erased and caused an exception in the debugger when trying to look at a sci_ch_ctrl_t structure at the _mdata location.
If I examine the elf file itself using xelfviewer, the location for _mflag contains the expected data.
However, when the firmware is first loaded, the debugger shows this memory does not have the values in the elf file. This indicates to me that the debugger is not correctly able to determine what ROM data it should be loading and seems to only be loading the executable code and not the initialisation data.
I can check the registers for this initialisation routine and these correctly contain the address for _data, _edata and _mdata as per the map file.
;;load data section from ROM to RAM
pushm r1-r3
mov #_mdata,r2 ;;src ROM address of data section in R2
mov #_data,r1 ;;dest start RAM address of data section in R1
mov #_edata,r3 ;;end RAM address of data section in R3
sub r1,r3 ;;size of data section in R3 (R3=R3-R1)
smovf ;;block copy R3 bytes from R2 to R1
I can look at the map file (using amap.exe) and see that my dflash sections are correctly defined with valid addresses in the expected location.
I can examine the elf file and see the correct data at _mdata.
The only thing that doesn't always show the correct data at the _mdata location is the debugger.
I should add, that this morning, both garbage collected and non garbage collected are working, no lines of code changed, just changing the linker script. I went to see if I could use the memory browser to show you what was different between the two _mdata areas.
The only thing I did differently at all was I accidently loaded another project into the debugger first.
Yesterday I did target power down / up, debugger power down / up, e2studio restart and every time, the garbage collected worked and the non garbage collected failed.
This is what is frustrating, because I then start writing real code and suddenly it will stop again, and when it does, it will be because the _mdata area in Flash has not been written. I will remove code and it will keep failing, I will go all the way back to what was working and it will hopefully work, then I will add something very basic and it will stop working and the whole cycle will go around.
So far, the only time I have not had it fail is when I have had garbage collection enabled. When the garbage collection is not enabled it will fail at some point, but there is no logical reason as to why.
It is as though the debugger thinks it doesn't need to write the _mdata area, so it doesn't do this and of course this means my code fails as all the peripheral initialisation depends upon this initialisation data being correct.
Sorry, there were changes between yesterday and today, I added in the buffers for Azure RTOS BSD support. there was no change at all to the linker script. With these buffers added and BSD initialised, now both garbage collected and non garbage collected work.
Dear Bazza, As long as you don't get consistent results, the problem is ambiguous. Please follow the below suggestions and see if you can find a consistent behavior or not.
- rebuild all the source files and make sure the compilation isn't skipped by the makefile script
- use the -O0 option to make sure the compiler doesn't optimize
- Erase all the memory blocks before overwriting it as below:
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.
Keep me posted about the results.
Happy debugging.
Hello Hossein
From my analysis the problem definitely lies in the debugger not correctly reading the elf file under some circumstances. The issue happens when the _mdata area is not written, this is the job of the debugger to load the code.
Without changing the linker file, just changing code, I can get a failure and a working version with garbage collection off. The fact the behaviour is not consistent is not ambiguous, it is an indication that some values in the elf file are confusing the debugger and making it think it doesn't need to write the _mdata area. What exactly it is that is confusing the debugger I don't know and possibly don't have the means to know. I can send you an elf file which will not load the _mdata if you want.
I have rolled back my code to the point I was having consistent failures and it once again crashes without garbage collection turned on but works with it turned on. Please not my project uses a lot of AZURE RTOS components. It first started to fail when I added the FIT module to allow me to program the data flash.
For the failed compile:
Here is the relevant part of the map file:
0x00000000ffec2924 ___dtors_end = .
0x00000000ffec2924 __DTOR_END__ = .
0x00000000ffec2924 . = ALIGN (0x2)
0x00000000ffec2924 _mdata = .
0x00000000ffec2924 _mdata2 = .
.data 0x0000000000000004 0x22ce load address 0x00000000ffec2924
0x0000000000000004 _data = .
*(.data)
*(.data.*)
.data.g_sdhi_ip_base
0x0000000000000004 0x4 ./src/smc_gen/r_sdhi_rx/src/targets/rx72n/r_sdhi_register.o
0x0000000000000004 g_sdhi_ip_base
.data.ch5_ctrl
0x0000000000000008 0x20 ./src/smc_gen/r_sci_rx/src/targets/rx72n/r_sci_rx72n_data.o
0x0000000000000008 ch5_ctrl
.data.ch3_ctrl
0x0000000000000028 0x20 ./src/smc_gen/r_sci_rx/src/targets/rx72n/r_sci_rx72n_data.o
0x0000000000000028 ch3_ctrl
The memory at the _mdata location is all FFFFFFFF, indicating erased flash.
0x00000000FFEC2924 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
Then I restore my current build which has code changes but no other changes.
Same linker script, same garbage collection turned off.
0x00000000ffec25ec ___dtors_end = .
0x00000000ffec25ec __DTOR_END__ = .
0x00000000ffec25ec . = ALIGN (0x2)
0x00000000ffec25ec _mdata = .
0x00000000ffec25ec _mdata2 = .
.data 0x0000000000000004 0x22ce load address 0x00000000ffec25ec
Now I correctly see the expected memory initialisation.
0x00000000FFEC25EC 0008AC00 FFE9FBC8 00000000 00000000 00000000 00000000 00000000 00000001 03938700 FFE9FC0C 00000000 00000000 00000000 00000000 00000000 00000001 03938700 FFE9FC50 00000000
The fact I can roll back and forward and get consistent results shows that the error is repeatable, but it is dependent upon certain things within the elf file.
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