Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fastbike opened this issue Jun 10, 2024 · 3 comments
Open

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

fastbike opened this issue Jun 10, 2024 · 3 comments

Comments

@fastbike
Copy link

fastbike commented Jun 10, 2024

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
Copy link
Author

fastbike commented Jun 10, 2024

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.

@fastbike fastbike changed the title Renases R7FA4M1: Unknown ARM Cortex-M Designer 423 Partno 16 M4 Renesas R7FA4M1: Unknown ARM Cortex-M Designer 423 Partno 16 M4 Jun 11, 2024
@perigoso
Copy link
Contributor

perigoso commented Nov 8, 2024

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
Copy link
Author

fastbike commented Nov 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants