If you encounter any issues after the upgrade, please open a support request TICKET.🙌
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.
Here are the a few tips and tricks for you to help with your development. We also have the frequently asked RA /FSP questions and answers to them. We also added a few tips and tricks to you with your developmentEach topic is provided in their own page for easy navigation and maintenance. Below is a list of available items.
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. The following is an example of how to use multiple pin configurations to enable and disable pins, further reducing power consumption in low-power mode (LPM).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.
Image Removed
In the Pins tab, click the “Manage configurations…” link.
Image Removed
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_lpm_cfg while the original configuration is called g_bsp_pin_cfg.
Image Removed
Use the function R_IOPORT_PinsCfg() along with the desired pin configuration to switch the active pin configuration on the MCU. In the LPM use case, this function will be called with the g_bsp_pin_lpm_cfg configuration to disable the unused pins before entering the LPM.
Image Removed
The unused pins will now be disabled, further reducing power consumption while in LPM.
Upon exiting LPM, the pin configuration can be switched back to re-enable the pins.
Image Removed
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.
Image Removed
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:
Image Removed
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:
Image Removed
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.
Image Removed
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.
Image Removed
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.
Image Removed
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.
Image Removed
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.
Image Removed
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.
Placeholder for configuring SPI channel for different targets
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.
Image Removed
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 Removed
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, P300/SWCLK/TCK and P201/MD pins connection using wired OR circuit on the target board to use both debugging and serial programming.
This tip shows you how to do it.
ID code protection allows or prohibits programming and on-chip debugging. The device checks the ID code provided by the debugger against an ID code stored in a special flash memory. This article describes where this special flash memory is, how to set it using FSP configurator, big or little endian considerations, and may other aspects of ID code protection for non-TrustZone RA devices.
Debugger Connectivity with ID Code Protection
TrustZone RA devices require specific hardware connections for debugging. Further, these devices must be in a correct Device Lifecycle Management (DLM) state to access Secure (S) Non-Secure (NS) and Non-Secure Callable (NSC) memory regions at different stages of a development process. Read more about it at below link.
Debugger Connectivity with TrustZone Devices
There are several RA Example Projects (EPs) and Application Projects (APs) distributed 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:
GitZip extension is available for Chrome, MS Edge, and Firefox. And it is free at here: https://gitzip.org/
See an example below.
Image Removed
They are distributed based on the officially supported RA boards. However, if you are only interested in EP for RA8D1 ADC module, you do not need to download all EPs for that board. Here is how.
An Easy Way to Download EP and AP Projects
Corporate work laptops have IT restrictions, often rendering the Microsoft Store inaccessible. Microsoft requires the Microsoft Store for the conventional installation of GUIX Studio, a GUI design application that is essential for UX designers whose product uses GUIX.
How to Install GUIX Studio Without Microsoft StoreLet'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!
Table of Contents |
---|