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.
Overview
Content Tools
