Page History

...

One SDK forms the building blocks of MCU firmware for BMS devices, and is the main focus on this design document.  It One SDK combines PDC Library and FG functionality such functionalities so that the same firmware code base can support any combination of the following functions:

...

Type-C Port Manager (TCPM)

...

and Fuel Gauge (FG)

...

, as well as supporting the firmware for Cell Characterization (CCHAR)

...

and Motherboard  Controller (MC)

...

.  TCPM typically works with a Type-C Port Controller (TPCP) to support USB-PD power negotiation up to 48V@5A.   FG typically works with an AFE (aka BMIC) to provide battery monitoring.  In both cases, the MCU+AFE combination can be a chipset, or fully encased in the same IC (i.e., co-pack).   Cell characterization Characterization (CCHAR) is a standalone daughtercard capable of cycling the battery cells over temperature.  CCHAR sequence will be orchestrated by the One GUI, with the proxy firmware running on the motherboard MCU

...

With the Secure Bundle, both customers and BMS apps team can customize a catalog device and overwriting the NS memory footprint of catalog firmware with the custom firmware.  The concept is illustrated in the figure below.  In this process only the catalog device need to be inventoried, as long as the custom firmware depends on the same Renesas MCU hardware and "Secret Sauce".

• How to call S code from NS code
• How to call NS code from S code

1.3.4  NS code calling S code

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

...

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

	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
     |    |    |    |    +---mcu
 
     +---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_clock_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_xml
     +---.cproject
     +---.secure_azone
     +---.secure_xml
     +---configuration.xml
     +S Debug.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.

...