...

When e2studio/FSP is used, the S project and NS project reside in the same workspace and are linked to one another.  

1.3.5 S code calling NS code

ddd

2.3 Create your first "Blinky" project

• S and NS co-reside in the same workspace
• Create Secure Project (S) - add Bootloader to set up S, NS and NSC memory map
• Show where S calls into NS code
• Create Non-secure Project (NS) - add  FreeRTOS
• Build and Run
• Show the S to NS code flow to end up blinking LEDs
• Show where to find the *.sbd file

1.3.3 One SDK supported MCUs

One SDK supports RL78, Cortex M0+, M23 and M33.  RL78 is largely for supporting legacy BMS FGIC.  Cortex M0+ is for 1S FGIC support.  Cortex M23 is largely for high-cell count BMIC support.  Cortex M33 is for high-cell count BMC/FGIC support and motherboard MCU support.  One SDK supported MCU shall have catalog firmware pre-programmed in Flash.  For M23 and M33 which has Trust Zone support, the IP shall be protected by Trust Zone.  None-secured firmware can be overwritten to reclaim the Flash memory.  Due to the lack of HW security, firmware for RL78 and M0+ have to be developed by Renesas to protect the firmware IP and limiting Flash data readout.  Below shows stated policy. The scenarios enclosed by dotted red lines are considered "sticky", i.e., customer developing fond dependence on due to attractive features, ease of use, or value gain.

Image Removed

2.0 One SDK Architecture

2.1 Overview

One SDK model consists of four layers plus a RTOS:

Hardware layer:  the physical hardware where applications built with One SDK runs.  The hardware can include MCU and external devices such as BMIC, TCPC, SPI Flash, Battery Chargers. etc.  

Driver layer (HAL): a collection of device drivers callable by the upper layer code to interact with the hardware.  Usually, each module in the driver layer is associated with a specific hardware component, e.g., UART, I2C, SPI, Flash, etc.  The driver layer is usually hardware specific.  For example, different MCU may require a different driver layer.  However, since different MCU often share the same peripheral blocks, the driver modules may be common between the MCUs.  

Middleware layer: a collection of processing modules that serve as the building blocks for constructing applications.  Each middleware module can be associated with a specific driver module, as in the case of protocol stacks, or associated with specific data-in, data-out functions or algorithms, such as FFT, or state-of-charge computation.  One can think of the middleware layer as a collection of building blocks to be sequenced by the application layer to create the application executables.  

Application layer:  a collection of loops/threads/interrupt handlers that form the top-level application logic. If threads are used, then RTOS would be required to facilitate scheduling, thread synchronization and inter-process communication.

Image Removed

Figure 1 - One SDK high-level architecture.

Application stacks:  each application stack is a collection of application threads and middleware modules that implements a specific application.  In One SDK each application stack is standalone and can be included or excluded at build time. For instance, if a MCU has only TCPM application stack, then the MCU would be a TCPM controller; but if it also has a FG application stack running then the MCU becomes a battery fuel gauge.  If both application stacks are included, then the MCU becomes a multi-function ASSP capable of functioning both as TCPM and battery fuel gauge, subject to MCU bandwidth limitation, available peripherals and memory capacity. 

2.2 Repository file structure

<One SDK follows RA e2studio/FSP project file structure, but also have extra folders for scripts, tools and docs.>

Describe not only how the repository is laid out, but also what the customer distribution package would look like.>

  e2studio can generate NSC veneer.

Image Added

Access to NSC drivers from a Non-secure project is possible through the Guard APIs. The FSP automatically generates guard functions for all the top-of-stack/driver APIs configured in the Secure project as Non-secure Callable.  Example below:

Image Added

1.3.5 Creating user-defined NSC functions

One can create a customized NSC API in the Secure project to expose only the top-level control of your algorithms and store the IP in the Secure Arm® Trust Zone® region. Precautions mentioned previously should be exercised during the creation of the user-defined NSC API.

The steps to create a customized NSC API are:

1. Create the Non-secure Callable custom function by declaring the function with BSP_CMSE_NONSECURE_ENTRY.
2. Create a header file that includes all the customized NSC function prototypes, for example, my_nsc_api.h.
3. Include the path to the NSC header using the Build Variable as shown in below figure.
4. Compile the Secure project to create the Secure Bundle. The NSC header will be automatically extracted for use in the Non-secure project.

Image Added

1.3.5 S code calling NS code

If FreeRTOS is selected and there is access to NSC functions from a Thread in the Non-secure project, it is necessary to enable Allocate secure context for this thread in the configurator for that Thread.

Image Added

1.3.6 USB debug interface setup

There are some prerequisites prior to setting up the MCU IDAU regions. From the factory, RA MCUs are delivered to the developer in the CM (Chip Manufacturing) lifecycle state. The MCU must be transitioned to SSD (Secure Software Development) lifecycle state prior to setting up the IDAU regions.  Transitioning from CM State to SSD State and setting up the IDAU region can only be achieved using the MCU’s boot mode, which can only be accessed using an SCI/USB connection. To benefit from the tools' support, developers need to bring the MCU Mode pin (MD) and SCI pins to the Debug interface. Special debugger firmware has been developed to manage to bring the device up in SCI boot mode to set up the IDAU registers (automatically drives MD pin) and then switch back to debug mode as needed. 

Image Added

<Verify that FSP-RA4E1 has the same>

When developing with e2studio and using Renesas evaluation kits for Trust Zone MCUs, the MCU is automatically transitioned from the CM state to the SSD state when the first secure program is downloaded to the MCU if the above required connection is provided.

1.3.6 Configure IDAU using e2studio

Renesas Device Partition Manager (RDPM) can be used to setup the IDAU regions.

Image Added

When using e2 studio, the necessary values to set up the Trust Zone® memory partition (IDAU registers) are calculated after the binary code to program into the Secure region is created by building the Secure project. The regions are set up to ensure that they match the code and data sizes and keep the attack surface as small as possible. If the hardware connection mentioned above is provided in the PCB design, there is no need to use the RDPM manually to set up the IDAU region. Setting up the IDAU region when developing with e2 studio is a transparent process for most applications.

2.3 Create your first "Blinky" project

• S and NS co-reside in the same workspace
• Create Secure Project (S) - add Bootloader to set up S, NS and NSC memory map
• Show where S calls into NS code
• Create Non-secure Project (NS) - add  FreeRTOS
• Build and Run
• Show the S to NS code flow to end up blinking LEDs
• Show where to find the *.sbd file

1.3.3 One SDK supported MCUs

One SDK supports RL78, Cortex M0+, M23 and M33.  RL78 is largely for supporting legacy BMS FGIC.  Cortex M0+ is for 1S FGIC support.  Cortex M23 is largely for high-cell count BMIC support.  Cortex M33 is for high-cell count BMC/FGIC support and motherboard MCU support.  One SDK supported MCU shall have catalog firmware pre-programmed in Flash.  For M23 and M33 which has Trust Zone support, the IP shall be protected by Trust Zone.  None-secured firmware can be overwritten to reclaim the Flash memory.  Due to the lack of HW security, firmware for RL78 and M0+ have to be developed by Renesas to protect the firmware IP and limiting Flash data readout.  Below shows stated policy. The scenarios enclosed by dotted red lines are considered "sticky", i.e., customer developing fond dependence on due to attractive features, ease of use, or value gain.

Image Added

2.0 One SDK Architecture

2.1 Overview

One SDK model consists of four layers plus a RTOS:

Hardware layer:  the physical hardware where applications built with One SDK runs.  The hardware can include MCU and external devices such as BMIC, TCPC, SPI Flash, Battery Chargers. etc.  

Driver layer (HAL): a collection of device drivers callable by the upper layer code to interact with the hardware.  Usually, each module in the driver layer is associated with a specific hardware component, e.g., UART, I2C, SPI, Flash, etc.  The driver layer is usually hardware specific.  For example, different MCU may require a different driver layer.  However, since different MCU often share the same peripheral blocks, the driver modules may be common between the MCUs.  

Middleware layer: a collection of processing modules that serve as the building blocks for constructing applications.  Each middleware module can be associated with a specific driver module, as in the case of protocol stacks, or associated with specific data-in, data-out functions or algorithms, such as FFT, or state-of-charge computation.  One can think of the middleware layer as a collection of building blocks to be sequenced by the application layer to create the application executables.  

Application layer:  a collection of loops/threads/interrupt handlers that form the top-level application logic. If threads are used, then RTOS would be required to facilitate scheduling, thread synchronization and inter-process communication.

Image Added

Figure 1 - One SDK high-level architecture.

Application stacks:  each application stack is a collection of application threads and middleware modules that implements a specific application.  In One SDK each application stack is standalone and can be included or excluded at build time. For instance, if a MCU has only TCPM application stack, then the MCU would be a TCPM controller; but if it also has a FG application stack running then the MCU becomes a battery fuel gauge.  If both application stacks are included, then the MCU becomes a multi-function ASSP capable of functioning both as TCPM and battery fuel gauge, subject to MCU bandwidth limitation, available peripherals and memory capacity. 

2.2 Repository file structure

<One SDK follows RA e2studio/FSP project file structure, but also have extra folders for scripts, tools and docs.>

Describe not only how the repository is laid out, but also what the customer distribution package would look like.>

	Project_Root
     +---.settings
     +---ra
     |    +---arm

	Non_Secure
     +---.settings
     +---ra
     |    +---arm
     |    |    +---CMSIS_6
     |    +---aws
     |    +---board
     |    +---fsp
     +---ra_cfg
     |    +---fsp_cfg
     |         +---bsp
     |         |    +---board_cfg.h
     |         |    +---bsp_cfg.h
     |         |    +---bsp_mcu_device_cfg.h
     |         |    +---bsp_mcu_device_pn_cfg.h
     |         |    +---bsp_mcu_family_cfg.h
     |         |    +---bsp_pin_cfg.h
     |         +---r_ioport_cfg.h
     |         +---rm_tz_context_cfg.h
     +---ra_gen
     |    +---bsp_block_cfg.h
     |    +---common_data.c
     |    +---common_data.h
     |    +---hal_data.c
     |    +---hal_data.h
     |    +---main.c
     |    +---pin_data.c
     |    +---vector_data.c
     |    +---vector_data.h
     +---script
     |    +---fsp.ld
     +---src
     |    +---hal_entry.c
     +---.api_xml
     +---.clangd
     +---.cproject
     +---.project
     +---.secure_azone
     +---.secure_xml
     +---configuration.xml
     +---NS Debug_SSD.jlink
     +---NS Debug_SSD.launch

    Secure
     +---.settings
     +---ra
     |    +---arm
     |    |    +---CMSIS_6 
     |    +---board
     |    |    +---ra4e1_fpb
     |    +---fsp
     |    |    +---inc
     |    |    +---src
     |    |    |    +---bsp
     |    |    |+---CMSIS_6
     |    +---cmsisaws
     |    |+---board
    |    |    +---mcufsp
 
     +---ra_cfg
     |    +---fsp_cfg
     |         +---bsp
     |         |    +---board_cfg.h
     |         |    +---bsp_cfg.h
     |         |    +---bsp_mcu_device_cfg.h
     |         |    +---bsp_mcu_device_pn_cfg.h
     |         |    +---bsp_mcu_family_cfg.h
     |         |    +---bsp_pin_cfg.h 
     |         +---r_ioport_cfg.h
     |         +---rm_tz_context_cfg.h 
     +---ra_gen
     |    +---bsp_clockblock_cfg.h
     |    +---common_data.c
     |    +---common_data.h
     |    +---hal_data.c
     |    +---hal_data.h
     |    +---main.c
     |    +---pin_data.c
     |    +---vector_data.c
     |    +---vector_data.h
     +---script
     |    +---fsp.ld
     +---src
     |    +---hal_entry.c
     +---.api_xml
     +---.clangd
     +---.core_xmlcproject
     +---.cprojectproject
     +---.secure_azone
     +---.secure_xml
     +---configuration.xml
     +---NS Debug_SSD.jlink
     +S---NS Debug_SSD.launch

   

  

2.3 Roles

One SDK envisions three different roles with successively greater privileges: users, OEM and factory.  Factory role is held solely by Renesas; OEM is usually the role of Renesas customers or ODM who purchase the devices containing the firmware; user role is assigned to consumers using the device containing firmware created using One SDK.

...

1. RA Flexible Software Package Users Manual
2. Security Design with ARM Trust Zone using Cortex M33
3. Renesas Device Life Cycle Management Key Injection
4. Renesas Device Life Cycle Management for Cortex M33
5. RA4E1 device data sheet
6. Segger J-Link RTT
7. J-Link Telnet Interface
8. J-Link SDK

...