...
One SDK leverages ARM Trust Zone for firmware IP protection. Trust Zone is a hardware-enforced code and data memory protection mechanism. In a TZ enabled MCU, memory and peripherals and peripherals are divided into two worlds: Secure (S) and Non-Secure (NS). After power-on-reset (POR), TZ-enabled MCU always enters the S world, typically running a bootloader or a startup code that sets up the boundaries of S and NS memories, with the protected IP stored in S memory, which can execute, but not read or written to as data. NS code can call S code and vise versa through special vector tables located in Non-Secure Callable (NSC) memory.
1.3.2.1 Secure and Non-Secure project organization
Renesas e2studio/FSP simplifies Trust Zone implementation by having S project and NS project co-exist and interoperate in the same workspace, such that when the compiled firmware is loaded into the MCU, S code/data are loaded into the TZ-protected memory, and NS code/data are loaded into NS memory. For every new NPI device requiring firmware, the BMS Firmware team will develop a complete catalog solution comprised of both S parts and NS parts.
If the MCU paired with the device supports TZ, then the BMS Firmware team will put the S parts in the S project, and the NS parts in the NS project. The combined catalog firmware pre-programed in the device during production. Instead of distributing both S project and NS projects, BMS Firmware team shall only distribute the Secure Bundle to customers and BMS apps team. The Secure Bundle comprises of NS source code plus the .sbd file containing linking information so that NS code can link to the S code without having the S source code.
1.3.3 Catalog device and custom firmware
With the Secure Bundle, both customers and BMS apps team can customize the a catalog firmware device and reclaim overwriting the NS code/data footprint, as is illustrated by the below figure. This process enables creation of a catalog device, and permitting the same catalog device to be customized. That means customers only needs to maintain a single inventory for all future customization based on the same version of firmware IP. This also means that whenever a major firmware IP is introduced, a new catalog device with a different part number is also introduced requiring separate inventory. memory footprint of catalog firmware with the custom firmware. The concept is illustrated in the figure below. In this process only the catalog device need to be inventoried, as long as the custom firmware depends on the same Renesas MCU hardware and "Secret Sauce".
How to call S code from NS code- How to call NS code from S code
...