SPRADK2 November 2024 F29H850TU , F29H859TU-Q1
The first step in configuring the SSU for an application is to determine the required system partitioning. The SSU provides three levels of hierarchy for partitioning the application subsystem:
This partitioning enables the third-party developer to develop, debug and maintain an application function on the same chip without requiring access to the primary user’s code and data assets. Furthermore, each user ZONE provides two levels of debug authorization:
As an example, a secondary user such as a third-party developer can debug an application module in ZONE2, and also be given partial debug access to ZONE1, so that the secondary user can effectively debug the application in context without having access to the primary user’s assets.
Each device has 3 user ZONEs available: ZONE1, ZONE2, and ZONE3. ZONE1 is the primary user ZONE; ZONE2 and ZONE3 are secondary user ZONEs.
.bss
,
.const
, and other linker output sections containing data
and variables.CPU1.LINK1
has some special fixed
permissions that enable access to certain system configuration
registers, in addition to AP-defined protections.CPU1.LINK2
is the system
security root LINK (SROOT), and has special fixed permissions
that enable access to system configuration registers and
override controls. This LINK typically executes privileged host
functions at the RTOS level. Figure 6-1 shows an example of SSU system partitioning on a single-CPU, single-ZONE system.
In this system, the RTOS runs in STACK2.LINK2
, and is responsible
for initializing system configuration, setting up peripherals and interrupts, and
starting the main execution loop. There are two control functions, Control
Loop1 and Control Loop 2. Each of these control functions is placed
in a separate Application Module (LINK), and both Application Modules are placed in
the same Sandbox. In this system, safety isolation is required between the two
control functions, but security isolation is not required between the two. A fourth
Module hosts communications code, such as UART or CAN-FD code. Because data coming
from an external interface can potentially pose a security threat to other functions
in the system, this Module is placed in a separate Sandbox. Finally, a fifth Module
contains common code functions which are shared between all the other Modules in the
system. The LINK associated with this module is defined as the Access Protection
Inheritance LINK (APILINK) for other LINKs. The Common Code Module is also placed in
a separate sandbox to maintain security isolation from the rest of the system (while
maintaining inherited permissions).
SysConfig includes full support for multicore applications. The built-in memory allocator tool automatically manages memory regions associated with application modules across multiple CPUs, and also manages the allocation of peripherals across the entire device. The SysConfig tool also includes a Shared Memory feature that enables the definition of memory regions that can be shared between modules on the same CPU or multiple CPUs.