Hi everyone,
We are excited to share two new demonstrations showcasing how hardware modules integrated into the NXP i.MX RT1170-EVK can enhance the safety of the MICROEJ VEE Port against memory corruption.
Link to the GitHub demonstration repository:
Memory Protection Unit (MPU) demo on Zephyr VEE Port
The main goal of this demonstration is to show how the ARM Memory Protection Unit (MPU) can be used to secure the memory of a MICROEJ VEE Port running on Zephyr RTOS.
Link to the MPU demo documentation:
What is the MPU ?
The MPU is an optional component in Cortex-M processor systems. In systems that require high reliability, the MPU can protect memory regions by defining access permissions for different privilege states. Refer to this ARM MPU documentation for more information.
Features
- Isolation of MICROEJ VEE memory from an untrusted native thread with the MPU.
- Safe data sharing between MICROEJ VEE and the authorized thread.
- Controlled corruption scenario to visualize the protection mechanism.
- Integration with Zephyr RTOS memory partitions and domains.
System Architecture
The demonstration is based on three native threads:
- 
Authorized Native Thread (runs in user mode) - Has access to the vee_partitioncontainingvee_data, a variable shared with the MICROEJ VEE.
- Can intentionally corrupt vee_data.
 
- Has access to the 
- 
MICROEJ VEE Thread (runs in supervisor mode) - Has unrestricted memory access.
- Executes the Java application.
 
- 
Unauthorized Native Thread (runs in user mode) - Does not have access to vee_datathrough the shared partition it belongs to.
- Any attempt to modify vee_datatriggers anMPU FAULT.
 
- Does not have access to 
Demonstration Workflow
- The MICROEJ VEE thread starts and periodically prints while vee_data = 0:
MICROEJ VEE : Hello World from Java
- The Authorized Thread starts and corrupts the vee_datavariable by setting it to 1. The MICROEJ VEE detects the corruption and prints :
MICROEJ VEE : Data corrupted
- The vee_datavariable is reset to its original value, the MICROEJ VEE thread restarts and periodically prints :
MICROEJ VEE : Hello World from Java
- The Unauthorized Thread starts and attempts to corrupt vee_data. This triggers anMPU FAULT, halting the system:
***** MPU FAULT *****
Data Access Violation
Result
The MPU enforces strict separation between native threads, preventing unauthorized native code from corrupting the MICROEJ VEE data.
NXP Extended Resource Domain Controller 2 (XRDC2) protection on FreeRTOS VEE Port
This demonstration showcases how the Extended Resource Domain Controller 2 (XRDC2) protects the memory of a MICROEJ VEE Port running on FreeRTOS against corruption caused by an Enhanced Direct Memory Access (eDMA) transfer.
Link to the XRDC2 demo documentation:
What is the XRDC2 ?
The XRDC2 provides an integrated, scalable architectural framework for access control, system memory protection, and peripheral isolation. It allows software to assign chip resources, including processor cores, non-core bus masters, memory regions, and slave peripherals to processing domains to support the enforcement of robust operational environments.
What is the eDMA ?
The eDMA controller is a second-generation module capable of performing complex data transfers with minimal intervention from a host processor.
Features
- Isolation of MICROEJ VEE memory from untrusted DMA accesses.
- Dynamic reconfiguration of XRDC2 access policies.
- Controlled eDMA transfers to demonstrate both blocked and allowed memory corruption.
- Detection of memory corruption at the Java application level.
System Architecture
This XRDC2 demonstration involves three main components :
- 
MICROEJ VEE Task - Runs on the Cortex-M7 core.
- Executes the Java application.
- Accesses a vee_datavariable stored in a protected memory region.
 
- 
eDMA Controller - Acts as a second bus master.
- Attempts to transfer data into the MICROEJ VEE memory region.
- Its access is either blocked or allowed by XRDC2.
 
- 
XRDC2 Controller - Assigns domain IDs to CM7 and eDMA.
- Defines access policies on memory regions.
- Dynamically reconfigures memory permissions during the demo.
 
Demonstration Workflow
- 
Initialization - XRDC2 is initialized.
- Domain IDs are assigned: CM7 (trusted), eDMA (restricted).
- MICROEJ VEE memory region is initially accessible to CM7, inaccessible to eDMA.
 
- 
MICROEJ VEE starts execution - Java app periodically prints :
 
MICROEJ VEE : Hello World from Java
MICROEJ VEE : Data value = false
- 
First eDMA transfer (denied) - XRDC2 denies eDMA access according to the access policies.
- Transfer fails, memory remains intact.
- MICROEJ VEE continues running normally.
 
- 
Second eDMA transfer (allowed) - XRDC2 reconfigures policy to grant eDMA access.
- eDMA successfully corrupts MICROEJ VEE data.
- Application detects corruption and stops :
 
MICROEJ VEE : Data corrupted
MICROEJ VEE : Data value = true
Result
The XRDC prevents bus masters like eDMA from unauthorized access, ensuring runtime resilience even against peripheral-driven attacks.
Learn more with hardware HardFault debugging with Debug a HardFault — MicroEJ Documentation
Happy coding!
The MicroEJ Team.


