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
Multiple pin configuration
Placeholder for creating multiple pin configurations
https://www.renesas.com/en/document/apn/getting-started-low-power-applications-ra2l1ra2e1-group
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.
This 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.
A code of all 0xFF indicates that the protection is turned off. This is a special case in which the debugger will not send an ID 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:
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. These bits are forced by the FSP. If the Locked mode is selected, the last byte is 0x8F, and the device is mode 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.
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 ID CODE in the connections settings tab of the debug launch configuration.
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.
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 idcode will lag changing the BSP id code by an iteration. That is, setting the idcode in the bsp, and then building, results in the idcode 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 code has changed). Now you need to disconnect the debugger, and change the idcode and connect again.
The ID_Code_ERASEALL script below can recover bricked devices, in certain cases.
Run-time SPI configuration
Placeholder for configuring SPI channel for different targets
Debugger connectivity with TrustZone devices
Placeholder for serial programming interface requirements to configure TrustZone IDAU registers
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:
- Select the files or the folders you want
- Click on Download
- 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!
Overview
Content Tools
