Overview

This page is for quick tips to help you with RA MCUs, its software, tools, and boards.  If you have any tips, please let us know and we will include them here.  

RA FAQs

Here are the frequently asked RA/FSP questions and answers to them.  We also added a few tips and tricks to you with your development.  

Multiple pin configuration

The FSP allows a user to create multiple pin configurations in the same project, and it also allows the application firmware to switch between these pin configurations during runtime.  With this, it is possible to change the peripheral setting of a pin or enable/disable pins entirely without having to manually reconfigure each pin.  One example of using multiple pin configurations is an application that goes into sleep mode to save power consumption.  The application can be setup with two pin configurations:  one while running normally (high-power) and another when in sleep mode (low-power). 

The FSP starts with a default pin configuration when the RA project is created, so a second pin configuration will need to be created.  The Pins tab of the FSP configuration viewer will allow you to create and modify different pin configurations.   Note the text box next to the “Generate data” checkbox.  This will be the name of the data structure which contains the pin configuration for use in the application code.

In the Pins tab, click the “Manage configurations…” link.

Here you can create an entirely new pin configuration or copy an existing one as a starting point.  In this example, the second pin configuration has most of the pins disabled, with one exception being the IRQ pin used to wake the MCU.  In the image below, you can see that the SPI0 pins that were enabled in the original configuration are now disabled.  Note that this configuration is called g_bsp_pin_cfg_lp while the original configuration is called g_bsp_pin_cfg_hp.

Depending on application requirements and where needed, you can call R_IOPORT_PinsCfg() to change the active pin configuration of the MCU.

Debugger connectivity with ID code protection

RA Devices without Trustzone incorporate ID Authentication for debugger protection.  Authentication is performed by comparing an ID CODE, stored in the MCU Flash, with an Authentication code sent by the debugger during connection.  Throughout the rest of this article, ID CODE refers to the code in the OSIS register (Option-setting memory in the diagram below) and Authentication code refers to the code sent by the debugger when it attempts to connect.

The ID CODE is implemented as a quartet of 32-bit values in the OSIS register (located at 0x0101_0018 in Flash memory) and presented as a 16byte value in the BSP tab of the FSP configurator:

Since this value is stored in Flash, a fully erased device will have an ID CODE consisting of all 0xFF.

An ID CODE of all 0xFF indicates that the protection is turned off.  This is a special case in which the debugger will not send an Authentication code, and tools like Segger Jflash will not ask for one on connect.  When the user wants to implement protection,  there are 2 methods from the pulldown:

• Locked with All Erase support
• Locked

If the device is Locked with All Erase support, then the debugger will not connect unless it sends the proper Authentication code.  However, if the debugger sends the “All erase” Authentication code the device will fully erase, and the ID CODE is set back to 0xFF’s.  This means that someone without the proper Authentication code can erase the device, and start over.  It is important to note that if the user has protected the block from erase, this trick will not work.

If the device is Locked, the debugger will not connect without the proper Authentication code.  There is no recovery from this.  This means that someone without the proper authentication code can NOT erase the device.

Consider the following ID CODE (0,1,2,3…,F) entered into the properties tab.

After building the project the OSIS register section in the srec looks like this:

(Note that the ID CODE is "spread out" with interleaving blocks of FFFFFFFF.  The ID CODE bits are color coded.  Consult the users manual for more details)

S3150101001800010203FFFFFFFF04050607FFFFFFFFBC

S3110101002808090A0BFFFFFFFF0C0D0ECFAC

To understand why the last byte is a CF rather than a 0F, look at the specifications for the id code protection in the UM.

Note that the data is big-endian, and the most significant bit, bit 127, is the MSB of the last byte of data in Flash.  Bits 127 and 126 are forced by the FSP.  If the Locked mode is selected, the last byte is 0x8F, and bit 126 of the ID CODE is 0 which indicates that protection without all erase support is selected.  There is also a permanently-locked state when bit 127 is a 0 that completely disables debugging (even with the proper code) but does allow the erase all.  To perform this, add the global define BSP_ID_CODE_LOCKED to the C/C++ preprocessor.

To see how this affects the code, search for BSP_ID_CODE_LOCKED and note this section in bsp_mcu_family_cfg.h.  The BSP forces the ID CODE to all 0x00. 

NOTICE!!!  In older versions this directive was named BSP_ID_CODE_PERMANENTLY_LOCKED. and some literature still says this.   

There is currently this article: https://en-support.renesas.com/knowledgeBase/20980158 that details the steps.  But, it has the outdated BSP_ID_CODE_PERMANENTLY_LOCKED,

Use instead BSP_ID_CODE_LOCKED

If the device is locked with all erase support, or permanently locked, it can be recovered by using a jlink and the ID_CODE_ERASEALL_RA2L1 script (link below).  Although the script says RA2L1, it will work for any RA device that uses this protection mechanism.

Keep in mind, if the AWS.FSPR bit is 0, or the security MCU is enabled, the AlErase will not work.

On the debugger side, the user specifies the Authentication code in the connections settings tab of the debug launch configuration.  The field is labeled ID Code, but we use the term Authentication code in this article to distinguish between the ID CODE in Flash and the code sent by the debugger on connection.

Note that on this end there is no manipulation of bits, and you need to understand and account for the 0xCF as opposed to 0x0F…that is the “real” authentication code.

The data here is the same byte-order as it is entered in the BSP configuration section.  There is a ellipse that brings up a dialog box allowing the Authentication to be entered in a variety of formats.

Also note that the OSIS registers CAN be programed like regular flash by code execution.  Therefore you could have a “safety net” program running on the MCU that would erase that section if you pressed a button or something.  This would allow exploring the behavior of the different modes without the fear of permanently locking up the device.

If you are experimenting with this, keep in mind that changing the debugger Authentication code will lag changing the ID CODE by an iteration.  That is, setting the ID CODE in the BSP, and then building, results in the ID CODE being in the srec.  However, the flash memory still contains whatever was programmed prior, so the connection is made with the old code.  Once the program is loaded, however, the debugger won’t work (because the ID CODE has changed).  Now you need to disconnect the debugger, and change the Authentication code and connect again.

The ID_Code_ERASEALL script below can recover bricked devices, in certain cases.

ID_Code_ERASEALL_RA2L1.zip  

Run-time SPI configuration

Placeholder for configuring SPI channel for different targets

Debugger connectivity with TrustZone devices

For debugging with Trust Zone (TZ) devices you need to first confirm the DLM (Device life Cycle management) state of the device. The device needs to be in the SSD state which has DBG2 debug level to have no restriction to access memories and peripherals for both Secure and Non-Secure partitions. Please note that the MCU can debug the non-secure assets only when the MCU is in NSECSD state, which has DGB1 debug level. The three debug levels are:

DBG2: The debugger connection is allowed, and no restriction to access memories and peripherals.

DBG1: The debugger connection is allowed and restricted to access only Non-Secure memory regions and peripherals.

DBG0: The debugger connection is not allowed.

The device current DLM state can be read and state can be initialized to SSD using the Renesas Flash Programmer (Renesas Flash Programmer (Programming GUI) | Renesas ) or using the Renesas Device Partition Manager, a tool integrated in the e2studio IDE and Renesas RA Smart Configurator.

Image RemovedImage Added

For the HW debug connection, you will also need Renesas E2, or E2 Lite, or SEGGER J-Link emulator to connect host machine to the Target board. The Target board will need a debug connector with the JTAG or SWD interface pinout as per the below table:

Image Removed

The debug connector will also need to support Serial Programming using SCI to program IDAU (Implementation Defined Attribution Unit) register. This will require Pin 4, SWCLK/TCK and MD pins connection using wired OR circuit on the target board to use both debugging and serial programming. Please note that for RA8 devices, the IDAU registers can be accessed using JTAG or SWD to set up the TrustZone® boundaries. Hence, Serial Programming using SCI Boot Mode is not required.

Easy way to download individual EP and AP projects

RA Example Projects (EPs) and Application Projects (APs)  distributed from GitHub at https://github.com/renesas/ra-fsp-examples. 

EPs are simple projects that show how a given RA peripheral can be setup and used.  EPs are listed based on officially available Renesas HW kits.  Some of these are  Evaluation Kits (EKs), Fast Prototyping Boards (FPBs), and Motor Control Kits (MCKs).   

APs are more involved projects that may utilize several peripheral to provide a solution.  For example, cloud connectivity or low power applications for specific Renesas HW kits.    

You can download EP and AP bundes in zip form from the GitHub site in Releases page.  This will allow you to get all EPs and APs.  However, this is a very large file and you may be interested in a one EP on a given kit.  How do you download only the EP or AP you want or need?

You do with GitZip Web extension.  With GitZip extension:

1. Select the files or the folders you want
2. Click on Download
3. Your selections will be in a zip file

GitZip extension is available for Chrome, MS Edge, and Firefox. And it is free at here: https://gitzip.org/

See an example below.  

Let's assume at you are working on a project with RA8D1.  You are interested in how ADC and AGT peripherals can be configured and used.  Then go to EK-RA8D1 EP folder and select ADC and AGT EPs.  Click on "Downloaded checked items".  Done!