...

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:

...

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 Privilege states

One SDK supports MCU with Trust Zone support or without.  For MCU with TZ, three privilege states are supported:  Factory (Renesas), Unsealed (OEM/ODM), Sealed (User).  For MCU without TZ support, only Unsealed and Sealed states are supported.  The meaning of each is defined below: 

...

Note that, in this case, there is no TZ support, therefore "secret sauce" code/data hiding is not possible.  Renesas must be the one doing the firmware customization and deliver only the executable binary.  

3.4.1 Top-level pseudo code

Below shows the factory bootloader pseudo code which would run right after reset: 

...

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 a host writing new code/data into secure and non-secure flash memories using the CMD_FLASH_WR command by parsing the Intel HEX file or Motorola S-Record file generated from the firmware build process.  Then the host can setup the Trust Zone memory boundaries 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

6.0 References

ddd