Renesas R7FA4M1: Unknown ARM Cortex-M Designer 423 Partno 16 M4

[fastbike]

The supported chip lists shows some Renesas R7FA parts, but notably the R7FA4M1 (RA4M1) part is not listed.

When attaching I get the error shown in the title.
Unknown ARM Cortex-M Designer 423 Partno 16 M4

I've looked in the renesas_ra.c file and can see some support for the RA family. There are defines for RA2A1 and RA4M2, there's an emum for PNR_SERIES_RA4M1, etc.

My guess is it is a simple matter of figuring out the correct parameters and creating a PR for the changes.

I'm reasonably new to this sort of thing so a few pointers on where to get started would be super helpful.

I have a EK-RA4M1 development kit and also a bread boarded 48QFP test circuit.
I'm using v2.3 of the genuine BPM from 1BitSquared.

The main differences I can see between RA4M1 and RA4M2 are

Attribute	RA4M1	RA4M2
Core	Cortex M4	Cortex M33
Speed	48MHz	100MHz
RAM	32kB	128kB
Flash	256kB	512kB

The RA4M1 comes in a 40QFN package with 5v tolerant pins so makes an easier transition for a legacy project I'm working on.

[fastbike]

The flash registers that store the chip identification and info have different locations.

Register	RA4M1	RA4M2
UIDR0-3	0x0100_3C00 + 14h/20h	0x0100_8190 + n × 4
PNR 0-3	0x0100_3C00 + 24h/30h	0x0100_80F0 + n × 4
MCUVER	0x0100_3C00 + 44h	0x0100_81B0

The base address shown for the RA4M1 is tagged as FMIFRT in the documentation. I notice there is code referencing this for some of the chips in the renesas_ra.c file

static target_addr_t renesas_fmifrt_read(target_s *target);

In addition the RA4M2 has a lot of other register controlling access to protection bits and the startup code. However these are probably not relevant to just reading from the chip.

My next question concerns the "magic numbers" in the renesas_ra.c file

#define RENESAS_PARTID_RA2A1 0x01b0U
#define RENESAS_PARTID_RA4M2 0x0340U
#define RENESAS_PARTID_RA4M3 0x0310U
#define RENESAS_PARTID_RA6M2 0x0150U

Where do these come from ? How would I add definitions for the RA4M1 ?

It also appears that even within the RA series there are two types of flash (MF3/4 and RV40)

Part	Flash Type
RA2A1	MF3
RA4M1	MF3
RA4M2	RV40
RA4M3	RV40
RA6M2	RV40

So does that will mean access to the flash will need to follow the code for the RA2A1 ? I note there is a comment in the code in function renesas_add_flash

/* FIXME: implement MF3/4 flash */

so it looks like this has not been made to work yet.

[perigoso]

Hey, this is quite old by now, sorry no-one got back to you, hopefully you still have the device at help to help us improve support for it.

First things first, it looks like your BMP is not identifying the Renesas Chip any further than as a ARM Cortex-M device, which is weird because the Renesas target implementation right now has some fallback functions to identify unsuported devices automatically.
Renesas target support should be enabled out of the box for a new enough version, assuming you are using the native probe, so something must be going on, to help identify what could you tell us what version of firmware is your probe running?

As for formally adding support, adding the ID just helps the debugger be more efficient identifying the device, but it should work out of the box as is, which should also allow you to debug the device
What is missing and requires some effort is implementing flash support for that architecture, which as you correctly identified, is different than that on some of the currently targets.

See #1243 and #1723

[fastbike]

Hi, thanks for the reply. I decided I needed to use my time solving the original problem i.e. writing the CAN bootloader for my R7FA4M1 device so went out and bought a JLink Mini (edu edition). This has worked.
But I'm sure there must be other folk who would like to use a versatile debugger/flash writer like the BMP. I don't really have the expertise or time to implement the flash writing code.