In this blog, we’ll discuss one of the most common issues that catch many people out when developing a “flat” application that uses the Ethernet controller on the RA Family Microcontrollers with Arm® TrustZone® technology. Currently, this covers the RA6M4 and RA6M5 microcontrollers.
Renesas has introduced TrustZone on our latest generation of microcontrollers based on the Arm Cortex®-M33 core. TrustZone provides a solution for application isolation to complement the advanced security features available on many of these products. TrustZone divides the MCU and application into secure and non-secure regions. Code in the secure region can access both secure and non-secure memory and device resources, but code in the non-secure region can assess only non-secure memory and device resources.
The ability to separate the secure and non-secure parts of your application is extremely useful for many applications, especially those concerned with IP protection and maintaining a strong Root of Trust for application updates.
While this ability to provide isolation is extremely useful for many applications, for other applications, isolation isn’t required. To support these use cases, it’s also possible to implement what we call a “flat” application, where TrustZone isolation is minimized.
A flat project exists (almost!) completely within TrustZone’s secure region. However, it’s important to understand that TrustZone is still active, so there can be some issues that we have to manage.
There are a few things that are important to understand:
- Any code placed in external memory (such as OSPI or QSPI) will be non-secure.
- The Ethernet Direct Memory Access Controller (EDMAC) is designed to be a non-secure bus master, so the associated Ethernet RAM buffers must be placed in non-secure RAM.
- In many cases, the development tools will automatically manage the required Device Lifecycle Management (DLM) manipulation and TrustZone boundary setting in the background. This must be manually duplicated for production programming.
In a flat project that includes the Ethernet controller, all code, data, and peripherals are placed in a single secure region, except for the EDMAC RAM buffers, which must remain in the non-secure region. This requires configuration of the Implementation Defined Attribution Unit (IDAU), which must be programmed into the nonvolatile memory using serial programming commands when the device lifecycle is in the Secure Software Development (SSD) state. For more information, see the Security Features section in your chosen RA microcontroller hardware manual.
It’s important to highlight here that to modify the TrustZone boundaries you will need access to the boot mode of the device, and you will need to do this even for a flat project if you are using Ethernet. This means that you not only need access to the debug interface but also to the boot interface of the device.
If you are having problems with the Ethernet controller on these devices, one of the first things we would recommend is that you check that the TrustZone boundaries are configured correctly in the IDAU and that the DLM state is set to SSD.
You can find more information about the benefits of TrustZone and how to develop applications using TrustZone in several application notes available on our website.
I hope this brief explanation of how TrustZone can affect the operation of the Ethernet controller on TrustZone-enabled RA 32-bit microcontrollers can help you identify and resolve any issues you might encounter.