A Flash Programmer error issue occurred when using E2 Lite

Hello,

This error occurs when a file that includes data that are out of the range of memory in the target device has been selected. If you do not wish this situation to produce an error, e.g. ignoring the data beyond the range of the memory does not create a problem, it can be changed to a warning. Regarding changing error messages to warnings, refer to “(6) Error Settings” in section 2.3.2, [Operation Settings] Tabbed Page.

I've tried deselecting "Enable address check of program file," but the program still doesn't run as smoothly as in the debugger.

I've attached the map file. Could you check for any abnormalities? Perhaps there're some mistakes
R7F100GGG_delete_mapped_section.txt.

What 'smoothly' means ? Does it run or not ? How do you check it ?

I cannot tell much from the .map file, the CS+ project may be more helpful.

I'm sorry, I made a mistake in my previous message. I meant that when flashing the program using Renesas Flash Programmer, it doesn't run. However, it runs smoothly via the CS+ debugger with E2 Lite.

Have you tried to disable the on-chip debug option when programming with RFP ?

I haven't tried that setting before. However, I deselected "Set enable/disable on-chip debug by link option (-ocdbg)" and flashed it into the MCU, but the result was the same—it didn't run

Sorry for informing you late. I’m using CS+ for CC.

Try to disable the RAM parity error resets by RPERDIS = 1. It is possible that without the debugger connected, some parts of RAM are not initialized when accessed, a RAM parity error occurs.

I've disabled the RAM parity error reset, but it still didn't run.

Please share your project for further review.

Looking at your attachment:

.textf
                                  000050cc  0001a929     1585e   1     TEXTF  (1a929+50cc=1F9F5)
.monitor2
                                  0001fe00  0001ffff       200   1     DATA_AT

There is overlap in the memory sections .textf and .monitor2.

The monitor section is required for debugging.  It would appear that you have simply run out of code-flash space.

Looking at your attachment:

.textf
                                  000050cc  0001a929     1585e   1     TEXTF  (1a929+50cc=1F9F5)
.monitor2
                                  0001fe00  0001ffff       200   1     DATA_AT

There is overlap in the memory sections .textf and .monitor2.

The monitor section is required for debugging.  It would appear that you have simply run out of code-flash space.

I think the .map file looks normal. Perhaps you misunderstood; "000050cc" is not the data size but the start address. I believe this doesn't overlap with the code flash section (50cc + 1585e = 1a92a). But I might be wrong. Could you explain why it exceeds the code flash section?

You are correct, the size is 1585e and the end is 1a929, sorry about that.

Can you share the HEX-file that you are trying to program with RFP, and a screen shot of the tool showing the error msg?

R7F100G-A01_ExxVxxLxx.zip

I have attached the hex file with this comment. Please check it.

Now the problem is pretty obvious.  For whatever reason, your .data is being place in RAM space, which cannot contain initialized memory.

Normally, the section ".data" is placed into ROM (code flash) and the corresponding RAM section is named ".dataR".  The C-startup initialization code will copy the ROM to RAM for proper initialization.

Your project appears to have changed from the auto-layout, and now the hex-file contains info at address FCFC6 which is outside of the programmable flash range.

S2140FCFC61200FF7F5802200330F8F8F800800100A1
S2140FCFD6000010381138153818381B3820382A38FC
S2140FCFE62D38313836383D3845384E385838643847
S2140FCFF671387F388E389F38B138C438D838F838F5
S2140FD00618391D3924392B393239413950395F3998
S2140FD0166E397D398C399B39AA39B939BC39C0393D
S2140FD026133800000000000000000000000000009B
S2140FD03600000000070000000000000000000000CF
S2140FD04600000000000000000000000000000000C6
S2140FD056000000000000000000000000D440D4408E
S2140FD066DA40DA40D840DA40DA40D840DA40D640DE
S2140FD076D840D640D640D840D640D440D440DA40E2
S2140FD086D440D840DA40D840D840DA40D840D840C6
S2140FD096D640D640D840D640DC40DC40DC40D440B4
S2140FD0A6D440D640D840D440DA40D640D440D640B6
S2140FD0B6DA40D840D640DC40DC40DC40D440D44092
S2140FD0C6D640D440D440DA40D640D440D640D64098
S2140FD0D6D840D640070107030303060304030000E0
S20E0FD0E6000000000000000044CF19
S2070FFEAA00000041
S9030000FC

Disabling the error checking in RFP is a really bad idea, this is producing the error for a reason.  It is no wonder the code doesn't run right with this error disabled, the initialized RAM is all garbage.

If you fix the section layout for initialized data this should solve your problem.

After trying to fix the layout of initialized data by adding the ROM to RAM mapped section

(before that we've deleted the ROM to RAM mapped section)
.data = .dataR
.sdata = .sdataR

It can compile completely, but a new problem has occurred.

It experiences a watchdog reset at a specific line of code or after a certain period of time. (For example, after downloading and running, the watchdog resets every 1.2 ms. at a same line of code every time)

We solved this problem by setting Locate ROM data to far area: Yes (-far_rom) (previously, we had set it to "No"). After this change, the problem was resolved, and the MCU can run properly. 


Question:
1. Can you give some advice why changing the setting (Locate ROM data to far area) fixed the issue and allowed it to work properly?
2. Why did the watchdog reset occur at a specific time when the "Locate ROM data to far area" setting was not enabled?

I've attached the .map file in case you need to check it.
map_file.zip

Off-hand I can offer no explanation of what you have observed.  I believe this would take some time to analyze the project and the operating conditions to understand what was happening.