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

Compare with Current View Page History

« Previous Version 9 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

Bootloader is the first firmware components that runs after MCU reset, and it runs in secure mode.  

3.4.1 Top-level pseudo code

The code block below shows the pseudo code of the bootloader.  After power-on-reset (POR), the MCU startup code shall call bootloader_start().  If the device is sealed, it will immediately call the NS_entry() function and start executing.  Note that g_dev_state is a SRAM variable.  If the device is unsealed prior to POR (e.g., gf_dev_state == STATE_UNSEALED) then bootloader will fall into a communication loop until it receives the CMD_RESET command which will cause the MCU to reset and restart the bootloader, except this time it will immediately call the NS_entry() function.  

While the communication loop is unsealed, the user can command the device to enter the factory state (STATE_FACTORY) through passphrase authentication.  This will unlock additional privileged commands in the process_cmd() that will only be avaialble if the device is in factory state.  


void bootloader_start()
{
   gs_dev_state = gsf_dev_state;

   if (gs_dev_state == STATE_UNSEALED)
   {
      bool done = false;
      while (!done)
      {
         rc = read_cmd(&cmd, param);
         if (rc == OK)
         { 
            if (cmd == CMD_RESET)
            {
               flash_write(&gsf_dev_state, STATE_SEALED);
               sys_reset();
            }
            else if ((cmd == CMD_FACTORY_AUTH) && (strcmp(param, gsf_passphrase))
            {
               gs_dev_state = STATE_FACTORY;
            }
            else
            {
               process_cmd(cmd, param);
            }
         }
         print_error(rc, cmd, param); 
      }
   }

   NS_entry();
}

3.4.2 Updating firmware

Firmware update involves writing new code and data to secure and nonsecure flash memories using the host CMD_FLASH_WR command.  The host PC shall parse an Intel HEX file into series of commands each follow by the checksum.  The Trust Zone memory boundaries are then configured by writing to the the IDAU registers.  

3.4.3 Generalized packet protocol

The bootloader communication shall be adaptable to any packet-based serial communication such as, UART, SMBus, SPI, TCP/IP socket, etc.  The device driver shall convert selected serial communication into packets, and a generlized packet driver process the commands.  


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 - RTT requires RA4E1 board modification
  • Algorithm API - include daughter card detection
  • AFE API - multi-daughter cards







  • No labels