You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

1.0 Introduction

This document describes the One SDK design, including the development environment.

2.0 Setup development environment

2.1 Install prerequisites

  • Install e2studio/FSP for RA
  • Install Python needed to support MCUBoot
  • Install Segger J-Link Software and Documentation

2.2 Introduction to Trust Zone

  • Secure after POR
  • Bootloader Set up S, NS and NSC memories
  • Describe S+NS side-by-side development model
  • Describe Secure Bundle distribution model
  • How to place "secret sauce" in secure memory
  • How to call S code from NS code
  • How to call NS code from S code

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 Nonsecure 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


3.0 SDK Architecture

3.1 Overview

One SDK model consists of four layers plus a RTOS:

Hardware layer:  the physical hardware where the application built with the SDK runs.  The hardware can be MCU registers, peripheral registers, memory, 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.

Figure 1 - One SDK high-level architecture.


Application stack:  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 the above example as only the TCPM application stack, then the MCU running the application would become a TCPM controller.  If only the FG application stack is included, 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. 


3.2 Supported MCU targets

  • RL78
  • CM0+
  • CM23
  • CM33

3.3 File structure

  • Closely following e2studio/FSP
  • Project/make files
  • S project
    • src
    • include
    • test
  • NS project
    • src
    • include
    • test
  • Scripts
  • Tools
  • Docs

3.4 Bootloader

  • Top-level flow chart or pseudo code
  • Set up Trust Zone memories
  • Update firmware
  • Validating S and NS FW code before jumping to it
  • Generalized API that can be adapted to any physical communication (e.g., UART, SMBus, SPI, etc.)


5.0 Application stacks

5.1 Application stack interface

  • Thread
  • Stack
  • Trigger events
  • Priority

5.2 Fuel gauge (FG) application stack

  • Introduction
  • Pseudo code of FG application thread
  • Security
  • Communication
    • SBS Data v1.1 support
    • Additional data support
  • Algorithm API
  • AFE API

5.3 TCPM application stack

  • Introduction
  • Pseudo code of TCPM application stack
  • Security
  • Communication
  • Algorithm API
  • AFE API

5.4 Motherboard application stack

  • Introduction
  • Pseudo code of motherboard application stack
  • Security
  • Communication
  • Algorithm API - include daughter card detection
  • AFE API - multi-daughter cards







  • No labels