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

Compare with Current View Page History

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


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 Factory Bootloader

One SDK bootloader flow supports three privilege states: 

  • Factory (STATE_FACTORY) – Factory mode.  MCU runs factory bootloader in S mode. Both secure and non-secure code/data can be read and written.  Factory mode can only be entered from unsealed state with factory command and factory password known only to Renesas.  Factory state is always exits to seal state with a self-reset. 
  • Unsealed (STATE_UNSEALED) – Unsealed state is only entered from the sealed state with unsealed command and customer password.  Unsealed state runs in NS mode and supports additional commands
  • Sealed (STATE_SEALED) – Sealed state is where application runs.  After reset, factory bootloader quickly check if it should enter the factory state; if not it will immediately transition to sealed state and jumps to the application.  

3.4.1 Top-level pseudo code


factory bootloader
void factory_bootloader()
{
   uint8_t cmd;
   uint8_t param[MAX_PARAM_SZ] = {0};

   gs_dev_state = gsf_dev_state;

   if (gs_dev_state == STATE_FACTORY)
   {
      flash_write(&gsf_dev_state, STATE_SEALED); 
      while (true)
      {
         bool rc = read_cmd(&cmd, param);
         if (rc == OK)
         { 
            if (cmd == CMD_RESET)
            {
               sys_reset();
            }
            else
            {
               rc = process_factory_cmd(cmd, param);
            }
         }
         print error(rc); 
      }
   }

   NS_entry();
}


The NS_entry() is the non-secure entry function.  Customer may optionally to implement customer bootloader() in NS_entry() or before the application code is called:

void NS_entry()
{
   application();
}


void application()
{
   // Initialize, setup ISR or threads
   application_setup();	

   
   // Comm loop 
   while (true)
   {
      uint8_t rc = read_cmd(&cmd, &param);
      if (rc == OK)
      {
         if (state == STATE_UNSEALED)
         {
            rc = process_unsealed_cmds(cmd, param);
         }
         else
         {
            if ((cmd == CMD_UNSEAL) && (0 == strcmp(param, customer_password))
            {
               state = STATE_UNSEALED;
            }
            else
            {
               rc = process_sealed_cmds(cmd, param);
            }
         }
      }
      print_error(rc);
   }
}


3.4.2 Updating firmware

Firmware update involves writing new code and data to secure and non-secure 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 generalized packet parser shall process the packets and execute valid 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