Renesas RA family flashing is not working properly

[perigoso]

while testing a RA4M2 dev board I found out on both RA4M2 and RA4M3 flashing is not working properly, something must have happened along the way in my original patch and I failed to notice while testing

consistently failing with:

flash is not ready, may be hanging mid unfinished command due to something going wrong, please power on reset the device

I will look into this myself, just documenting the issue. the whole flashing logic could get a rewrite, I based it on renesas first party code logic, but I see that might have been a mistake

[perigoso]

Known working targets:

• RA6M2

Known non-working targets:

• RA2A1
• RA4M2
• RA4M3

[krzysztofgawrys]

@perigoso any news on that issue?

[perigoso]

No, I no longer have access to Renesas ICs or Dev boards (job change) so i don't have the means to test or fix the issue.

And you should expect the issue to still be present, if it was fixed it was by coincidence

[krzysztofgawrys]

Thank you for fast response. In that case I will have a look at that issue.

I happens that I do have both, custom PCBs with RA4M2 and original Renesas EV Kit for RA4M2 with onboard debug probe.

[perigoso]

That would be great, I can give more info about it next week, when I can look at things again to get a refresher

[krzysztofgawrys]

@perigoso your code works well except for missing Option-Setting flash memory region, this flash region is CF PE type but not writable like normal CF flash, 44.9.3.15 of RA4M2 User's Manual, working on that fix

[perigoso]

Hm, that's surprising, maybe one of @dragonmux's unrelated correctness fixes did improve things, but good to hear

[krzysztofgawrys]

I cannot reproduce original issue: flash is not ready, may be hanging mid unfinished command due to something going wrong, please power on reset the device

however I stepped across new issue where flashing memory fails with error:

Loading section .text, size 0xa84 lma 0x0 Error writing data to flash

solution for me was to limit SWJ freq to some low speeds (100kHz),

(gdb) tar ext :2000 Remote debugging using :2000 (gdb) mon s Target voltage: 3.14V Available Targets: No. Att Driver 1 R7FA4M2AB3CNE M33 (gdb) attach 1 Attaching to program: /mnt/c/Users/kgawrys/e2_studio/workspace/blink_led/Debug/blink_led.elf, Remote target bsp_prv_software_delay_loop (loop_cnt=158198) at ../ra/fsp/src/bsp/mcu/all/bsp_delay.c:166 166 __asm volatile ( (gdb) load Loading section .text, size 0xa84 lma 0x0 Error writing data to flash (gdb) mon freq 100k Current SWJ freq 100000Hz (gdb) load Loading section .text, size 0xa84 lma 0x0 Loading section .data, size 0x8 lma 0xa84 Loading section .option_setting_ofs, size 0x10 lma 0x100a100 Loading section .option_setting_sas, size 0x4 lma 0x100a134 Loading section .option_setting_s, size 0xd0 lma 0x100a200 Start address 0x000007f8, load size 2928 Transfer rate: 276 bytes/sec, 418 bytes/write. (gdb)

this can be issue with probe itself (tested with PROBE_HOST=hosted and STLinkv2), needs more testing

In #1450 added partial support for Option-Setting Flash memory

[perigoso]

Sounds like the original issue could somehow be related, and a lot of the work done in the meantime was related to timing, that could justify different behavior. Anyhow, good work!

[perigoso]

Hey @mtk11, did you try using RA2A1 recently (reference for everyone else #1243)? seeing that the original issue was not reproducible having another data point would be useful, if you could test the latest firmware it would be great!

Edit: actually, looks like I did a fairly gross misdiagnosis when you originally posted your issue, your target RA2A1 uses the MF3 flash architecture, which I did not implement, only the RV40, my bad! good news is there's no issue with that part, bad news is flashing is not supported right now :sweat_smile: .

[rizqicy]

Hi, I just got RA6M1 and RA6M5 in my hand and give a try loading the elf file to those MCU with blackmagic. Here is my test result:

Blackmagic Fw version	RA6M1	RA6M5
v1.9.2	flashing and loading ok	failed to flash
v1.10	failed to flash	failed to flash

FYI, I use stlink hardware and compile the blackmagic firmware from the branch v1.10 and release tag v1.9.2 gdb and debug output from bmp attached, did I use the BMP correctly? 😅

anyway, I can help with testing for these 2 targets and just let me know.

RA6M1 blackmagic v1.9.2 (gdb).txt RA6M1 blackmagic v1.10 (gdb).txt RA6M5 blackmagic v1.9.2 (gdb).txt RA6M5 blackmagic v1.10 (gdb).txt RA6M1 debug_bmp v1.9.2.txt RA6M1 debug_bmp v1.10.txt

[dragonmux]

Many thanks for all the logs - those will be very helpful indeed! You are using BMP correctly, this is just a particularly tricky set of parts to correctly support and the support is still quite experimental. For example, both of those parts are actually missing their proper part numbers in the renesas.c target support source and are being detected via a fallback path (your logs will let us plug that gap).

Both the RA6M1 and RA6M5 should have worked - they're both RV40 type Flash parts, which is the implemented and supported kind of Flash. That the RA6M1 stopped working since v1.9.2 indicates a regression (hopefully the logs will help understanding what exactly). Somewhat more concerning is that the RA6M5 didn't work at all on either version of the firmware.

We'll work with Perigoso to review the data provided and try and come up with a fix, keeping this issue updated.

[sebromero]

Hi! I have the same issue with RA6M5. However, it does flash fine with 1.9.2:

Loading section .option_setting, size 0x38 lma 0x100a100
Loading section .option_setting_s, size 0xcc lma 0x100a200
Loading section .text, size 0x17d90 lma 0x10000
Loading section .ARM.extab, size 0xcc lma 0x27d90
Loading section .ARM.exidx, size 0x198 lma 0x27e5c
Loading section .data, size 0x1168 lma 0x27ff4
Start address 0x00016294, load size 103008
Transfer rate: 10 KB/sec, 936 bytes/write.

While with v1.10.2 I get:

Loading section .option_setting, size 0x38 lma 0x100a100
Loading section .option_setting_s, size 0xcc lma 0x100a200
Loading section .text, size 0x17d90 lma 0x10000
Error writing data to flash

With both versions I have to execute set mem inaccessible-by-default off before running the load command, but I guess that's as expected. Since it works with the older version, I wonder what caused the regression? Any hints?

[dragonmux]

The target Flash layer got a major overhaul and there have been many other changes between the two firmware version series' - given it works in 1.9.2 and you have a working setup, we would suggest running a git bisect between the v1.9.0 and v1.10.0 tags and seeing at what commit it stops working.

If you can get that information and drop it here, it will give us some insights as to which specific change actually broke it and possibly also what needs to happen to fix it.