Rich set of system-level services included in the Synergy Software Package (SSP) and fully integrated with the ThreadX® RTOS. Application programming interfaces (APIs) abstract device-specific components, allowing access to MCU features without needing to interact with lower-level software or hardware. APIs simplify and accelerate application software development and code reuse across products built on the Synergy Platform.

Real-Time Operating System

Connected IoT devices have multiple concurrent events happening in real-time. Managing this complexity requires robust execution and timely response from the CPU and/or Direct Memory Access (DMA) channels to service individual event requests in a deterministic manner. Using a Real-Time Operating System (RTOS) with built-in thread prioritization and scheduling services is the simplest and most effective way to achieve this, ensuring consistent and responsive performance.

Real-Time Operating System

ThreadX® RTOS

Thread  X RTOS


An advanced RTOS from Express Logic designed for everything from high-end applications to resource-constrained embedded products.

ThreadX® provides advanced synchronization features such as messaging services, interrupt management, and Preemption-Threshold™ scheduling, in addition to Event-chaining™ and a picokernel™ architecture for highly efficient execution. This widely-used RTOS, which has been deployed in over 5 billion electronic products in the consumer, medical electronics, and industrial control markets, meets numerous important safety and quality standards.


picokernel™ Architecture

Lean RTOS design enabling faster response times.

ThreadX® leverages a picokernel™ architecture that plugs kernel services directly into its core, rather than layering them on top of one another as in traditional microkernel architectures. This results in highly efficient context switching and service call performance.


Event-chaining™ Technology

Enables synchronization of multiple events, resulting in fewer threads, less overhead, and smaller SRAM requirements.

ThreadX® uses notification capabilities to “chain” various synchronization events together. Instead of having separate threads to check for queue messages, event flags and semaphores, an application can now receive notifications for each object.


Preemption-Threshold™ Scheduling

Allows high-priority threads to interrupt lower priority threads, providing timely responses to important application events.

ThreadX® addresses many typical synchronization problems by allowing threads to temporarily change their preemption threshold, offering greater control and flexibility.

Application Framework

Collection of individual frameworks providing rich functionalities with simple APIs.

The frameworks are integrated with ThreadX® to manage resource conflicts and synchronize between threads. This saves developers time since they no longer need to reinvent commonly used services and do not typically need to interface directly with the hardware. It also leads to shorter development cycles by enabling code re-use across processors.

Application Framework

Application Framework

Application Framework

Audio Framework

Enables playback of audio content, handling synchronization of multiple hardware components.

Handles the required synchronization of multiple peripherals, including timers, Direct Memory Access (DMA) Controller, and Digital-to-Analog converter (DAC) for seamless audio playback. It supports uncompressed, 16-bit mono linear Pulse Code Modulated (PCM) samples and output of audio via multiple peripherals.

Application Framework

SPI Framework

Handles serial communication with devices connected via the SPI peripheral or Serial Communication Interface (SCI) peripheral, configured in SPI mode.

The SPI Framework provides a single interface for both the SPI and SCI peripherals and calls the appropriate lower-level driver. It supports a single bus or multiple buses, multiple slaves on a single bus, and bus control/locking features.

Application Framework

Console Framework

Receives commands and input strings via the UART, processes the input, and calls the appropriate routine.

The Console Framework is the basis for implementing a command line interface (CLI). It receives commands and input strings via the UART, parses the content, and calls the relevant command handler routine. It can also handle inputs from other serial interfaces such as the USB Communication Device Class (CDC).

Application Framework

I2C Framework

Handles serial communication with devices connected via the I2C peripheral or Serial Communication Interface (SCI) peripheral, configured in I2C mode.

The I2C Framework provides a single interface for both peripherals and calls the appropriate lower-level driver. It provides mutual exclusion and synchronization services to manage simultaneous access requests.

Application Framework

JPEG Decode Framework

Enables run-time JPEG decoding, leveraging the on-chip acceleration hardware.

The JPEG Decode Framework provides the ability for applications to specify parameters such as horizontal and vertical subsample values, horizontal stride, decoded pixel format, input and output data format, and color space. It also supports streaming encoded input data, allowing an application to read and decode from a file or network without buffering the entire image.

Application Framework

UART Framework

Implements full-duplex serial communication, with support for multiple hardware peripherals.

The UART Framework supports full-duplex serial communication with devices connected via the Serial Communication Interface (SCI) or USBX™ Communication Framework, using the Communication Device Class (CDC) Abstract Control Model (ACM) protocol.

Application Framework

Touch Panel Framework

Receives input events from multiple touch screens and captures user input for software processing.

The Touch Panel Framework provides a seamless and thread-safe interface for configuring and controlling external touch screens via the Inter-Integrated Circuit (I2C) bus. The framework supports receiving input events from multiple touch screens and leverages the internal Messaging Framework to ensure prompt delivery to the application.

Application Framework

Thread Monitor Framework

Monitors threads and issues an MCU reset if improper thread behavior is detected.

Thread execution is tracked using specific variables assigned to each thread. The Thread Monitor checks these variables and issues an MCU reset if any fall outside their expected range.

Application Framework

Messaging Framework

Enables reliable communication by passing messages between threads.

The Messaging Framework supports message management features, including flags and handshaking, to allow inter-thread communication. It also allows threads to subscribe to notifications from specific message queues and can trigger execution of a callback function when a message is sent to a queue. 

Application Framework

ADC Framework

Provides access to control and configuration functions for the A/D converter (ADC), such as the sampling rate and sampling threshold.

The ADC samples and buffers data at the specified rate, notifying the application once the configured number of samples is available. The ADC Framework uses either the General Purpose Timer (GPT) or the Asynchronous General Purpose Timer (AGT) interface for timing functions and efficiently transfers data to applications using the integrated Direct Memory Access (DMA) Controller or Data Transfer Controller (DTC).

Application Framework

Capacitive Touch Sensing Framework

Provides a generic API for capacitive touch applications using ThreadX®. The Capacitive Touch Sensing Framework creates a private thread that drives a hardware scan of a capacitive touch panel and updates the panel at a periodic rate.

Application Framework

Power Profiles Framework

Controls system clocks, I/O ports, operating modes (indirectly through the clock control), and low power modes.

The Power Profiles Framework gives the user advanced control over MCU power consumption. It provides two main functions, run and sleep, to control MCU power consumption while leveraging low power mode HAL drivers, and supports both threaded and non-threaded operations.

Application Framework

Block Media Interface Framework

Handles access to media devices, simplifying application code and enabling easy swapping of media devices.

The Block Media Interface Framework abstracts media drivers so they appear functionally identical at the file I/O layer, eliminating the need for code changes when swapping media devices. The Block Media Interface Framework achieves this by using function pointers instead of direct function calls. Functions are called between FileX® and the block media drivers, such as Secure Digital Multi-Media Card (SDMMC) and SPI flash.

Application Framework

X-Ware™ Interface

The SSP uses several X-Ware™ components from Express Logic: ThreadX® RTOS, NetX™ IPv4 and NetX Duo™ TCP/IP stacks, NetX Secure™, USBX™ USB Host/Device protocol stack, FileX® MS-DOS compatible file system, and GUIX™ graphics runtime library. A series of Application Frameworks in the SSP simplifies use in end-applications.

Application Framework


Network security protocol that replaces Secure Sockets Layer (SSL) protocol and enables secure communication between client and server.

The Transport Layer Security (TLS) protocol provides a mechanism to encrypt messages between client and server to prevent unauthorized access. The client and server perform a TLS handshake to generate session keys, which are used by the application to encrypt data. The protocol also uses authentication to verify identity, and hash values to ensure data integrity. The system detects errors that may be considered a potential security breach and uses TLS alerts to notify client and server. This TLS implementation supports TLS versions 1.0, 1.2 (plus version 1.1 beginning 2Q18)  and adheres to the RFC 5246 standard.

Application Framework


Lightweight messaging protocol utilizing a publish/subscribe model, designed for resource-constrained applications.

The Message Queue Telemetry Transport (MQTT) protocol allows clients, such as sensors and other network devices, to publish messages. Other clients on the network can subscribe to receive messages, which are relayed through a broker. This reduces code complexity and size on embedded devices, as they do not require knowledge of other devices.

MQTT uses multi-leveled topics to describe and categorize messages. Clients can subscribe to specific topics to receive corresponding messages. MQTT supports three Quality of Service (QoS) levels, providing flexibility in prioritization of messages.

Application Framework

Wi-Fi Framework

Provides abstraction layers for the Wi-Fi module device driver, consisting of a set of APIs, a Network Stack Abstraction Layer (NSAL), an SSP HAL interface, and a vendor-provided Wi-Fi device driver.

The Wi-Fi APIs provide a generic interface for configuring and operating the Wi-Fi module, eliminating the need for the application to directly interact with the hardware or low-level driver.

Synergy MCUs can run the network stack locally, or use a set of APIs to interface with a stack running on an external Wi-Fi module.

When the network stack runs on the Synergy MCU, the NSAL implements the MAC layer using the Wi-Fi APIs. This layer is then used by the NetX™ and NetX Duo™ network stacks.

The SSP HAL interface adapts the low-level driver that is specific to each Wi-Fi module.

Application Framework

BLE Framework

Provides a set of APIs to advertise, scan, and connect with devices, and supports Generic Attributes (GATT) features such as service discovery, and reading and writing characteristics.

The BLE Framework provides a set of generic APIs to support Central and Peripheral Generic Access Profile (GAP) roles, and corresponding features to facilitate connection. It allows setting of the BLE operating mode, security mode, bonding mode, and other parameters. The API set also supports GATT profiles running on an external BLE module. These include the following profiles: Find Me, Proximity, Blood Pressure, Heart Rate, and Alert Notification.

The BLE framework offers flexibility to run a third-party BLE communication stack locally on the MCU or on an external BLE module.

Application Framework

Cellular Framework

Provides abstraction layers for LTE cellular modules, consisting of a set of APIs, a Network Stack Abstraction Layer (NSAL), a SSP HAL Interface, and a Cellular Device Driver.

The Cellular APIs include a set of generic cellular drivers that provide basic functionality, and module-specific drivers that can override functions as needed.

The NSAL establishes a point-to-point communication channel and performs any authentication selected. It calls the appropriate API to send and receive cellular data.

The SSP HAL interface adapts the low-level driver that is specific to each cellular module. 

Application Framework

External Interrupt Framework

Handles interrupts as binary signals originating from hardware external to the MCU such as other integrated circuits, pushbuttons, and power supply monitors.

As with all SSP frameworks, the External Interrupt Framework is ThreadX®-aware and uses semaphores to synchronize interrupts. It can be used to route the interrupt to a thread or to trigger a transfer via the Event Link Controller (ELC).

The External Interrupt Framework supports requests for up to 16 hardware channels and can handle unique pending Interrupt Requests (IRQs) for multiple threads. In addition, the framework provides an API that allows the suspension of threads while waiting for external IRQ requests.


The SSP includes a suite of Express Logic middleware components that are fully integrated with the ThreadX® RTOS, consisting of the NetX™ IPv4 and NetX Duo™ TCP/IP stacks, NetX Secure™, USBX™ USB Host/Device protocol stack, FileX® MS-DOS compatible file system, and GUIX™ graphics runtime library.





A high-performance MS-DOS-compatible file system, fully integrated with the ThreadX® RTOS.

Like ThreadX®, FileX® is designed to have a small footprint and high performance, making it ideal for today's deeply embedded applications requiring file operations. FileX® supports 12-, 16-, and 32-bit File Allocation Table (FAT) formats and contiguous file allocation, and is highly optimized for both size and performance. It also supports various storage media such as USB mass storage, SD/MMC card, on-chip flash, and SPI flash.



A complete graphical user interface suite including a full-featured runtime UI library and integrated with ThreadX®.

Designed to have a small footprint of less than 6KB, GUIX™ only integrates features used by the application into the final image. Fast interface response is achieved through minimal function call layering and highly optimized clipping, drawing, and event handling. Service names are straightforward, making it easy to use and integrate.



Complete USB host and device stacks, with support for low speed, full speed, and high-speed devices.

The USBX™ host core stack ensures devices are properly detected and configured and offers support for cascading hubs, multiple configuration devices, and composite devices. USBX™ device mode can support a complex device framework that includes multiple configurations, interfaces, and alternate settings. The USBX™ device string framework accommodates multiple languages to provide maximum flexibility.


NetX™, NetX Duo™, and NetX Secure™

The SSP includes two high-performance implementations of TCP/IP standards, NetX™ and NetX Duo™, that are fully integrated with ThreadX®. Both modules provide zero-copy communication to eliminate processor cycles consumed by moving data to and from user buffers.

NetX™ provides a streamlined, IPv4-capable TCP/IP stack, whereas NetX Duo™ offers both IPv4 and IPv6 capabilities. Both modules are built on a unique Piconet™ architecture to minimize image size by integrating only the services required by the application.

NetX Duo™ includes support for the following protocols:

·         ARP/RARP

·         MQTT

·         DHCP

·         NAT

·         DNS

·         POP3

·         FTP

·         PPP

·         TFTP

·         SMTP

·         HTTP

·         SNMP

·         ICMP

·         Telnet

·         IGMP

·         UDP

·         BSD Socket Library


NetX Secure™ provides enhanced network security features including Transport Layer Security (TLS).

Functional Libraries

Collection of libraries, provided by Renesas and other vendors, offering highly optimized C-callable functions outside of a framework.

Functional libraries communicate directly with the HAL and are pre-tested, qualified, and verified by Renesas. New libraries are regularly released to provide developers with new features and functionality.

Functional Libraries Structure

Functional Libraries Structure

Functional Libraries

Cryptography and Security Library

Collection of APIs enabling a wide range of security features including macro-level security functions, root-of-trust, and the ability to recognize trusted sources and code.

The Cryptography and Security Library utilizes hardware-accelerated crypto HASH algorithms and symmetric and asymmetric crypto key algorithms, and provides True Random Number generator support.

Cipher types include: AES 128/192/256, SHA1, SHA224/256, DES, 3DES, ARC4, DSA 1024/2048, HRK, RSA

Functional Libraries


Industry standard abstraction layer for digital signal processing (DSP) algorithms and functions, designed specifically for MCUs using Cortex®-M processor cores.

The Arm® Cortex® Microcontroller Software Interface Standard (CMSIS) for DSP simplifies software re-use and reduces the learning curve for developers. The CMSIS DSP Library Collection has over 60 functions for various data types, including fixed-point (fractional q7, q15, q31) and single precision floating-point (32-bit).

Functional Libraries

Software Safety Library

Collection of software functions that operate the MCU’s safety self-check features, reporting the status to the application layer. Software safety libraries are certified in accordance with the IEC-60730 Safety Standard for Household Appliances and IEC 61508 Safety Standard for Functional Safety.

Hardware Abstraction Layer (HAL)

Software drivers providing access to Synergy MCU peripherals, enabling highly portable code and insulating the developer from interacting directly with the hardware.

The Hardware Abstraction Layer (HAL) consists of two layers, a Low-Level Driver (LLD) and a High-Level Driver (HLD). The LLD interfaces directly with the peripheral registers and can be used with all Synergy MCUs containing the IP. The HLD provides an efficient way to develop portable code that is independent of hardware.

Hardware Abstraction Layer

Hardware Abstraction Layer

Hardware Abstraction Layer (HAL)


Supports full-duplex Controller Area Network (CAN) communication and configuration.

The CAN HAL driver allows for bit timing configuration as defined in the CAN specification and can be configured for up to 32 transmit or receive mailboxes with standard or extended ID frames. Receive mailboxes can be configured to capture either Data or Remote CAN frames. The driver also supports user callback functions that can be executed when a transmit, receive, or error interrupt is triggered.

Hardware Abstraction Layer (HAL)


Configures and operates the Serial Communications Interface (SCI) peripheral for full-duplex UART communication.

The UART HAL driver implements interrupt-driven data transmission and reception, callback functions, run-time baud rate changes, hardware flow control, Data Transfer Controller support, and more. 

Hardware Abstraction Layer (HAL)


Configures and operates the SD/MMC Host Interface (SDHI) for connectivity with external SD cards and embedded MMC (eMMC) devices.

The SDHI driver supports read, write, and control commands for connected devices. It can also be used with a compatible file system such as FileX® or as a standalone SDIO card driver.

Hardware Abstraction Layer (HAL)


Handles erasing and programming the contents of attached Quad SPI (QSPI) flash devices.

The QSPI HAL driver supports the QSPI peripheral on Synergy MCUs, which functions as a memory controller for connecting a serial ROM (non-volatile memory such as a serial flash memory, serial EEPROM, or serial FeRAM) with an SPI-compatible interface.

Hardware Abstraction Layer (HAL)


Configures and operates the Serial Peripheral Interface (SPI) for communication with external devices.

The SPI HAL driver performs SPI initialization and configuration and supports 8-, 16- and 32-bit data transfers. User-defined callbacks can be used to signal when the SPI has transmitted data, aborted a data transfer, or detected an error condition. The SPI driver also supports configuration of GPIO pins as chip selects.

Configures and operates the Serial Communication Interface (SCI) peripheral for master-based SPI communications.

The SCI SPI HAL driver performs functions such as SPI initialization and clock configuration. User-defined callbacks can be used to signal when the SPI has transmitted data, aborted a data transfer, or detected an error condition. The SCI SPI HAL driver supports data transfers using the Data Transfer Controller (DTC), offloading the CPU.

Hardware Abstraction Layer (HAL)


Configures and operates the Inter-Integrated Circuit (I2C) peripheral for communication with external devices.

The SSP provides two I2C HAL drivers, one each for master and slave operation. The drivers support interrupt-driven transmit and receive processing, with callback functions for each. The I2C module supports bit rates of 100 Kbps, 400 Kbps, and 1 Mbps.

Hardware Abstraction Layer (HAL)


Configures and operates the Serial Sound Interface (SSI) for audio communication using the Inter-IC Sound (I2S) protocol.

The SSI driver operates the SSI peripheral in master mode, typically sending and receiving uncompressed audio data. The driver supports the following features: full-duplex I2S communication (SSI channel 0 only), interrupt-driven data transmission and reception, and integration with the DTC transfer module.

Hardware Abstraction Layer (HAL)


Provides access to the I/O Ports at both bit and port levels.

The IOPort HAL driver configures the ports and pins as input or output. In addition, several configuration APIs are provided to change the functionality of individual pins.

Hardware Abstraction Layer (HAL)

Parallel Data Capture Unit

Captures image data from a camera or image sensor module connected to the PDC peripheral.

The Parallel Data Capture Unit (PDC) driver includes functions to initialize peripherals, start image capture, and close the interface. It supports callbacks to notify the CPU when a capture has been completed and provides a pointer to the capture buffer.

Hardware Abstraction Layer (HAL)

Capacitive Touch Sensing Unit

Configures and operates the Capacitive Touch Sensing Unit (CTSU) for use with capacitive touch interfaces.

The CTSU driver provides the functionality to open, close, run, and control the peripheral. It detects any input to the touch screen, performs the appropriate filtering, and provides the touch data to higher-level drivers for further processing.

Hardware Abstraction Layer (HAL)

ADC12 HAL drivers

Configures and operates the A/D converter (ADC), providing the ability to perform a single scan, continuous scan, or group scan.

The 12-bit A/D converter (ADC12) HAL driver allows both hardware and software triggers for starting scans and triggering interrupts after conversions.

Hardware Abstraction Layer (HAL)

ADC14 HAL drivers

Configures and operates the A/D converter (ADC), providing the ability to perform a single scan, continuous scan, or group scan.

The 14-bit A/D converter (ADC14) HAL driver allows both hardware and software triggers for starting scans and interrupt triggering after conversion.

Hardware Abstraction Layer (HAL)


Configures and operates the dual-channel D/A converter (DAC) to output one of 4096 discrete voltage levels.

The 12-bit D/A converter (DAC12) driver provides flexibility for selecting an internal or external reference voltage and features an anti-interference mode to operate synchronously with the ADC module.

Hardware Abstraction Layer (HAL)

DMA Controller

Configures and operates the Direct Memory Access Controller (DMAC) peripheral to perform background data transfers.

The DMAC driver transfers data between memory and peripherals, or between two peripherals without CPU intervention. It moves data from a user-specified source to a user-specified destination when an interrupt or event occurs. 

Hardware Abstraction Layer (HAL)

Data Transfer Controller

Configures and operates the Data Transfer Controller (DTC) peripheral to perform background data transfers.

The DTC driver transfers data between memory and peripherals, or between two peripherals without CPU intervention. It moves data from a user-specified source to a user-specified destination when an interrupt or event occurs. The DTC also supports chained transfers in which more than one transfer may occur after a single activation source interrupt.

Hardware Abstraction Layer (HAL)

Event Link Controller

Uses event requests to link peripherals together without CPU intervention.

The Event Link Controller (ELC) manages connections between peripherals and can generate events that activate the Data Transfer Controller (DTC). It includes functions to create or break a link between two blocks and to generate events to interrupt the CPU.

Hardware Abstraction Layer (HAL)

Code Flash

Provides functions for reading, writing, and erasing application code located on the MCU High-Performance Flash memory block.

Synergy MCUs include non-volatile code flash memory providing high-speed access to application code. While the amount of flash memory available varies across MCU devices, all MCUs support the following four blocking operations for code flash: reading, writing, erasing, and blank checking.

A write protection feature is available to prevent accidental overwriting of critical areas of memory. In addition, a swap area for boot block swapping allows safe re-writing of the startup program without first erasing it.

Hardware Abstraction Layer (HAL)

AGT 16-Bit Timer

Configures and accesses the Asynchronous General-Purpose Timer (AGT) peripheral, providing pulse measurement, pulse generation, event counting, and interrupt generation capabilities.

The AGT driver can be used to trigger I/O events, data transfers using the DMAC/DTC, MCU wakeup, or activity on another peripheral through the ELC.

Hardware Abstraction Layer (HAL)

Independent Watchdog Timer

Configures and operates the Independent Watchdog Timer (IWDT) peripheral, providing a fail-safe mechanism to reset the device or trigger a non-maskable interrupt.

The IWDT is run from a dedicated clock and consists of a 14-bit down counter that must be serviced periodically to prevent underflow. The IWDT driver provides the ability to read and refresh the timer, and read and clear status flags. 

Hardware Abstraction Layer (HAL)

Data Flash

Provides functions for reading, writing, and erasing application data located on the MCU flash memory block.

Synergy MCUs include non-volatile data flash memory that provides high-speed access to application data. While the amount of memory available varies across MCU devices, all MCUs support the following operations for data flash: blocking reading, writing, erasing and blank checking; non-blocking reading, writing, erasing and blank checking; and callback functions for completion of non-blocking data flash operations.

Hardware Abstraction Layer (HAL)

GPT 32-Bit

Configures and operates the General Pulse Width Modulation Timer (GPT) peripheral for waveform generation and other timer functions.

The 32-bit GPT timer can be used to generate pulse-width modulated (PMM) waveforms such as saw and triangle waves, or as a general-purpose timer. The GPT driver includes functions to start and stop the timer and configuration options such as waveform period, waveform duty cycle, and ELC-based triggers. The driver also provides an output compare extension to output the timer signal to the GTIOC pin.

Hardware Abstraction Layer (HAL)

Watchdog Timer

Configures and operates the Watchdog Timer (WDT) peripheral, providing a fail-safe mechanism to reset the device or trigger a non-maskable interrupt.

The WDT consists of a 14-bit down counter that must be serviced periodically to prevent counter underflow. The WDT driver provides the ability to configure the WDT, read/refresh the timer, and read/clear status flags. 

Hardware Abstraction Layer (HAL)


Configures and operates the Real Time Clock (RTC) peripheral for clock and calendar functionality.

In addition to standard calendar functionality, the RTC supports a binary counting mode for non-Western calendars. The driver accesses time, date, and alarm values, configures RTC and event notification settings, and enables activation of other peripherals. 

Hardware Abstraction Layer (HAL)

Interrupt Controller Unit

Configures and operates the Interrupt Controller Unit (ICU) peripheral for detecting external pin interrupts from push-buttons, external integrated circuit devices, and other interrupt sources.

The External Interrupt Request (IRQ) driver allows enabling and disabling of interrupts, designates user callback functions, and provides a variety of interrupt configuration options.

Hardware Abstraction Layer (HAL)

Keyboard Interrupt Control

Supports the Key Interrupt (KINT) Function peripheral for handling keyboard input.

The KINT driver can be used for one to eight channels or in a matrix format. The driver generates an interrupt when keyboard input is detected and executes a user-specified callback function.

Hardware Abstraction Layer (HAL)

Clock Generation Circuit

Supports on-chip clock generation for the CPU and its peripherals.

Clock Generation Circuit (CGC) capabilities include selection from several clock sources, frequency division, clock stability check, and power management. The driver can return the frequency of the system and system peripheral clocks at run time, as well as provide a callback function when the main oscillator has stopped.

Hardware Abstraction Layer (HAL)

Low Voltage Detection

Provides access to and configuration of the on-chip voltage monitor peripheral to detect a drop in supply voltage.

The Low Voltage Detection (LVD) driver gives early warning to the application software when the voltage level of on-chip operating voltage is out of range. The monitor status consists of two flags: one to indicate whether the voltage is currently below the threshold, and another to indicate whether it has crossed the threshold at any point. The LVD driver configures the voltage threshold, response action, and callback function address (when appropriate), along with other settings. The driver also allows reading and clearing of the LVD status.

Hardware Abstraction Layer (HAL)

Factory MCU Information

Reads factory information from flash, indicating available MCU features.

The Factory MCU Information (FMI) driver provides a generic API for reading records from the Factory MCU Information Flash Root Table (FMIFRT) that is populated on each Synergy MCU, and indicates to the application software the specific MCU features available at run time. This capability is used to configure all SSP modules that require MCU-specific information at the time of initialization.

Hardware Abstraction Layer (HAL)

Graphics LCD Controller

Provides an API for generating a display in applications using a RGB color TFTLCD panel with a color depth of up to 24 bits.

The Graphics LCD Controller (GLCDC) driver allows for Color Look-Up Table (CLUT) usage for input graphic planes with 512 words (32 bits/word). The GLCDC driver also allows for adjusting the output, including brightness, contrast, and gamma correction. The GLCDC can blend two input graphics planes using a ping-pong buffer that avoids the tearing that frame buffer systems often show. 

Hardware Abstraction Layer (HAL)

Segment LCD Controller

Controls the Segment LCD Controller (SLCDC) on Synergy S3 Series MCUs.

The SLCDC driver initializes the controller and configures the voltage generator to output the appropriate waveform to the display. It also provides configuration options, including functions to update the display output, configure the display area, and adjust contrast.

Hardware Abstraction Layer (HAL)

JPEG Codec

Configures and operates the JPEG peripheral that performs high-speed image data compression and decoding of JPEG image data.

The JPEG Codec driver also supports streaming of encoded data, allowing an application to read an encoded JPEG image from a file or network while decoding, without needing to buffer the entire image. The driver also contains built-in error checking that returns an error when a JPEG image’s height or width does not match the specified input values. The JPEG Decoder conforms to the JPEG baseline decompression standard, JPEG Part 2, ISO-IEC10918-2.

Hardware Abstraction Layer (HAL)


Configures and operates the Cyclic Redundancy Check (CRC) peripheral for ensuring data integrity.

The CRC driver can calculate 8-, 16-, and 32-bit values on blocks of data that reside in memory or on a stream of data over a serial channel. The driver performs CRC calculation using various types of industry standard polynomials.

Board Support Package

Performs system initialization after power-on or reset, and all functions necessary to reach the main() function in the user’s application.

The Board Support Package (BSP) performs initialization functions such as setting up stacks, heap, clocks, interrupts, and C runtime environment. It consists of MCU-specific, board-specific, and generic code and APIs. All Synergy Kits and MCUs are supported by a BSP. To generate the board level support for your own circuit board and application, use the BSP API.


Clear and Protected SSP Source Code

Three types of SSP licenses are available depending on the use case and required level of source code access.

The SSP consists of clear source code and protected source code. Clear source code can be edited and saved regardless of the license. Protected source code can be viewed or edited with the appropriate SSP license. Typical product development does not require modification of protected source code, and most products can be taken to production without source code alteration.

Viewing, editing, and debugging of SSP source code requires use of a supported development environment such as the e2 studio Integrated Solution Development Environment (ISDE) or the IAR Embedded Workbench® for Renesas Synergy™.

SSP License Types

The SSP is distributed under three different license types. The table below summarizes licensing options.

License Feature


Development / Production

Source Code**

License fees or royalties




License application

Synergy Website

Synergy Website

Renesas sales representative

Synergy Account type




License delivery source

Synergy Website

Synergy Website

Synergy Website

Access to all SSP functions




Warranted to operate per SSP datasheet


1 year upon taking license

During purchased maintenance period

Maintenance – access to SSP update and upgrade releases



1st year maintenance included in license purchase. Extensions to maintenance periods can be purchased

Access to source code

Clear source code

Use, view, edit, save

Use, view, edit, save

Use, view, edit, save

Protected source code


Use, view

Convert any SSP versions released during the maintenance period to clear source code. Use, view, edit, save*

Use terms

Use is governed by Evaluation License terms

Use is governed by Dev and Production License terms

Use is governed by Source Code License purchase terms

Usage case

Initial evaluation, rapid prototypes and demos, student projects.

Development of end-product and release to mass production.

Requirement for clear-text files of protected SSP source code modules, possibly required for:

·         Company policy compliance

·         Software certification by 3rd party

·         Modification of protected SSP source code (rarely necessary)


* continued use, viewing, editing and saving of the previously converted SSP clear-text files is valid after maintenance period has ended, but no conversions of protected code to clear-text in new SSP releases are possible after maintenance period ends.

** Source Code License

Most end products can be developed and taken to production without the need for a source code license. In rare cases, it may be necessary to obtain viewable and editable files of protected SSP source code. This may be required by company policy, independent certification requirements, or for a required modification of a certain function.

A source code license allows conversion of protected SSP source code to viewable and editable code for any SSP release that occurs during the maintenance period. An extension may be purchased to convert SSP releases after the initial maintenance period.



Renesas consistently maintains the SSP on the Synergy Gallery, providing new SSP versions for bug fixes, feature and performance enhancements, and optimizations.

SSP maintenance updates are available with a valid SSP license and are included in the price of any Synergy MCU with no renewal fees. SSP maintenance is provided as long as Synergy MCUs are supported by Renesas.

Release Maturity

As a release progresses through the development cycle, a level of maturity (e.g. Preview, Alpha, Beta, and Mass Production [MP]) is assigned at each stage. The following table enumerates the criteria required for each stage and for whom the release is intended.


Feature / Bug State

Released to



Not all features implemented, available ones are functional but not necessarily complete.

Regression testing and some integration testing done.

Specific customers for directed testing or integration.



Feature complete.

SQA for full feature integrated testing.

Generally, not released publicly.

Some features may have bugs.


All Blocker bugs fixed.

Beta testers (may be internal or external).


Mass Production

All Blocker and Critical bugs fixed.

Ready for release.

Everyone, if public release.

Specific customers, if private release.

If an MP release is done during SQA cycle and post Beta release, it will have an RC tag.

As noted in the table above, a Release Candidate (RC) has MP maturity, but the SQA cycle has not been completed. Releases prior to Mass Production are not generally available except under special circumstances.