SSP v Release Note. Renesas Synergy Platform Synergy Software Synergy Software Package. Release Note

Transcription

1 Release Note SSP v1.2.1 Release Note Renesas Synergy Platform Synergy Software Synergy Software Package All information contained in these materials, including products and product specifications, represents information on the product at the time of publication and is subject to change by Renesas Electronics Corp. without notice. Please review the latest information published by Renesas Electronics Corp. through various means, including the Renesas Electronics Corp. website ( Rev.1.04 Aug 2017

2 Notice 1. Descriptions of circuits, software and other related information in this document are provided only to illustrate the operation of semiconductor products and application examples. You are fully responsible for the incorporation or any other use of the circuits, software, and information in the design of your product or system. Renesas Electronics disclaims any and all liability for any losses and damages incurred by you or third parties arising from the use of these circuits, software, or information. 2. Renesas Electronics hereby expressly disclaims any warranties against and liability for infringement or any other disputes involving patents, copyrights, or other intellectual property rights of third parties, by or arising from the use of Renesas Electronics products or technical information described in this document, including but not limited to, the product data, drawing, chart, program, algorithm, application examples. 3. No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights of Renesas Electronics or others. 4. You shall not alter, modify, copy, or otherwise misappropriate any Renesas Electronics product, whether in whole or in part. Renesas Electronics disclaims any and all liability for any losses or damages incurred by you or third parties arising from such alteration, modification, copy or otherwise misappropriation of Renesas Electronics products. 5. Renesas Electronics products are classified according to the following two quality grades: "Standard" and "High Quality". The intended applications for each Renesas Electronics product depends on the product s quality grade, as indicated below. "Standard": Computers; office equipment; communications equipment; test and measurement equipment; audio and visual equipment; home electronic appliances; machine tools; personal electronic equipment; and industrial robots etc. "High Quality": Transportation equipment (automobiles, trains, ships, etc.); traffic control (traffic lights); large-scale communication equipment; key financial terminal systems; safety control equipment; etc. Renesas Electronics products are neither intended nor authorized for use in products or systems that may pose a direct threat to human life or bodily injury (artificial life support devices or systems, surgical implantations etc.), or may cause serious property damages (space and undersea repeaters; nuclear power control systems; aircraft control systems; key plant systems; military equipment; etc.). Renesas Electronics disclaims any and all liability for any damages or losses incurred by you or third parties arising from the use of any Renesas Electronics product for which the product is not intended by Renesas Electronics. 6. When using the Renesas Electronics products, refer to the latest product information (data sheets, user s manuals, application notes, "General Notes for Handling and Using Semiconductor Devices" in the reliability handbook, etc.), and ensure that usage conditions are within the ranges specified by Renesas Electronics with respect to maximum ratings, operating power supply voltage range, heat radiation characteristics, installation, etc. Renesas Electronics disclaims any and all liability for any malfunctions or failure or accident arising out of the use of Renesas Electronics products beyond such specified ranges. 7. Although Renesas Electronics endeavors to improve the quality and reliability of Renesas Electronics products, semiconductor products have specific characteristics such as the occurrence of failure at a certain rate and malfunctions under certain use conditions. Further, Renesas Electronics products are not subject to radiation resistance design. Please ensure to implement safety measures to guard them against the possibility of bodily injury, injury or damage caused by fire, and social damage in the event of failure or malfunction of Renesas Electronics products, such as safety design for hardware and software including but not limited to redundancy, fire control and malfunction prevention, appropriate treatment for aging degradation or any other appropriate measures by your own responsibility as warranty for your products/system. Because the evaluation of microcomputer software alone is very difficult and not practical, please evaluate the safety of the final products or systems manufactured by you. 8. Please contact a Renesas Electronics sales office for details as to environmental matters such as the environmental compatibility of each Renesas Electronics product. Please investigate applicable laws and regulations that regulate the inclusion or use of controlled substances, including without limitation, the EU RoHS Directive carefully and sufficiently and use Renesas Electronics products in compliance with all these applicable laws and regulations. Renesas Electronics disclaims any and all liability for damages or losses occurring as a result of your noncompliance with applicable laws and regulations. 9. Renesas Electronics products and technologies shall not be used for or incorporated into any products or systems whose manufacture, use, or sale is prohibited under any applicable domestic or foreign laws or regulations. You shall not use Renesas Electronics products or technologies for (1) any purpose relating to the development, design, manufacture, use, stockpiling, etc., of weapons of mass destruction, such as nuclear weapons, chemical weapons, or biological weapons, or missiles (including unmanned aerial vehicles (UAVs)) for delivering such weapons, (2) any purpose relating to the development, design, manufacture, or use of conventional weapons, or (3) any other purpose of disturbing international peace and security, and you shall not sell, export, lease, transfer, or release Renesas Electronics products or technologies to any third party whether directly or indirectly with knowledge or reason to know that the third party or any other party will engage in the activities described above. When exporting, selling, transferring, etc., Renesas Electronics products or technologies, you shall comply with any applicable export control laws and regulations promulgated and administered by the governments of the countries asserting jurisdiction over the parties or transactions. 10. Please acknowledge and agree that you shall bear all the losses and damages which are incurred from the misuse or violation of the terms and conditions described in this document, including this notice, and hold Renesas Electronics harmless, if such misuse or violation results from your resale or making Renesas Electronics products available any third party. 11. This document shall not be reprinted, reproduced or duplicated in any form, in whole or in part, without prior written consent of Renesas Electronics. 12. Please contact a Renesas Electronics sales office if you have any questions regarding the information contained in this document or Renesas Electronics products. (Note 1) "Renesas Electronics" as used in this document means Renesas Electronics Corporation and also includes its majority-owned subsidiaries. (Note 2) "Renesas Electronics product(s)" means any product developed or manufactured by or for Renesas Electronics. (Rev November 2016)

3 Release Note Renesas Synergy Platform R11UT0017EU0104 Rev.1.04 Contents 1. Introduction Release information Synergy MCU groups supported Software Tools and Hardware Kits used for SSP Testing Version Information for Express Logic, Inc. software components SSP release package and installation information Changes from SSP v1.2.0 to SSP v1.2.1 release Updated Features SSP Quality and Performance sf_el_ux r_lpmv Auto Initialization Summary of bug fixes since SSP v Crypto/r_sce GUIX Studio NetX, NetxDuo NetX App Layer Properties nx_ftp_common nx_dhcp nx_dhcp_server nx_dns nx_ftp_server nx_http_server nx_telnet_server nx_tftp_server nxd_ftp_common nxd_bsd nxd_dhcp nxd_dhcp_server nxd_dns nxd_ftp_server nxd_http_server R11UT0017EU0104 Rev.1.04 Page 1 of 53

4 nxd_nat nxd_telnet_server nxd_tftp_server tx_src nx_ftp_client, nx_ftp_server, nx_http_server, nx_tftp_server, nxd_ftp_client, nxd_ftp_server, nxd_http_server, nxd_tftp_server, fx r_adc r_agt r_cac r_can r_crc r_ctsu r_flash_lp r_gpt r_icu r_kint r_lvd r_qspi r_riic r_sdmmc r_spi sf_el_gx sf_el_nx sf_el_nx_comms sf_el_tx sf_el_ux sf_el_ux_comms sf_message sf_touch_panel_i2c Synergy Tools USBX Device Development ux XML Configurations BSP XML License File r_sci_i2c sf_spi sf_i2c r_cgc r_lpmv r_fmi R11UT0017EU0104 Rev.1.04 Page 2 of 53

5 9. Known Issues and limitations in SSP v1.2.1 that were identified since SSP v1.2.0 release r_rspi ux sf_el_ux sf_jpeg_decode nx r_sci_i2c GUIX integration r_sci_uart Synergy Software Configurator r_gpt_input_capture r_gpt_input_capture, r_lpm r_lpm, r_lpmv sf_el_gx sf_el_ux_comms sf_audio_playback sf_external_irq sf_el_fx sf_spi Crypto/r_sce File System r_sci_spi r_riic r_crc SSP XMLs for ISDE Hardware Additional Usage Notes for SSP v ux sf_el_ux GUIX integration r_cgc sf_el_gx NetX Code Cleanup sf_el_fx r_rtc r_adc r_qspi Crypto/r_sce r_ctsu R11UT0017EU0104 Rev.1.04 Page 3 of 53

6 10.14 sf_power_profiles Complete list of modules available in this release Additional Technical Notices Appendix I: ARC SCE ARC4 Driver Usage Guide Crypto Interface What Does the SCE ARC4 Module Do? Getting Ready to Write a Crypto Application Using e 2 studio to write an ARC4 Crypto Application ARC4 Example using ARC4 Driver on r_sce_arc ARC4 Interface Interface API Data structures Variables Defines g_sce_crypto_api g_arc4_on_sce API Structures arc4_ctrl_t arc4_cfg_t open keyset arc4process close versionget arc4_instance_t SCE ARC R_SCE_ARC4_Open R_SCE_ARC4_Close R_SCE_ARC4_Process R_SCE_ARC4_VersionGet R_SCE_ARC4_KeySet R11UT0017EU0104 Rev.1.04 Page 4 of 53

7 1. Introduction This document describes the release notes for Synergy Software Package (SSP) version R11UT0017EU0104 Rev.1.04 Page 5 of 53

8 2. Release information SSP Release Version v1.2.1 Release Date May 26, 2017 Important notices for this release: The intended audience for this release is Renesas Synergy customers, prospective customers, partners, and support staff. R11UT0017EU0104 Rev.1.04 Page 6 of 53

9 3. Synergy MCU groups supported S7G2, S3A7, S124, S5D9 groups. R11UT0017EU0104 Rev.1.04 Page 7 of 53

10 4. Software Tools and Hardware Kits used for SSP Testing Tool Version Description e 2 studio IAR EW for Synergy SSC GNU ARM Compiler eabi-4_9-2015q win32 Software development environment. Link: Software development environment. Link: Synergy Standalone Configurator. Used in combination with IAR EW for Synergy. Link: GNU ARM compiler GCC_ IAR Compiler IAR ARM compiler toolchain PE-HMI1 2.0 Product Example (PE) for Human Machine Interface to evaluate SynergyS7G2 Group MCU DK-S Development Kit for Synergy S124 Group MCU DK-S7G2 3.1 Development Kit for Synergy S7G2 Group MCU SK-S7G2 3.1 Starter Kit for Synergy S7G2 Group MCU DK-S3A7 2.0 Development Kit for Synergy S3A7 Group MCU PK-S5D9 1.0 Promotion Kit for Synergy S5D9 Group MCU J-Link Software 6.14b Segger J-Link debug probe R11UT0017EU0104 Rev.1.04 Page 8 of 53

11 5. Version Information for Express Logic, Inc. software components Component ThreadX 5.7 NetX 5.9 NetX Duo NetX Application bundle NetX Duo Application bundle USBX TM Host USBX TM Device FileX Version 5.10 SP2 5.9 SP SP2 5.7 SP7 5.7 SP4 5.4 SP2 GUIX TraceX GUIX Studio R11UT0017EU0104 Rev.1.04 Page 9 of 53

12 6. SSP release package and installation information This package contains SSP v1.2.0 minor release and SSP v1.2.1 patch releases; the installer installs SSP v1.2.0 and applies the SSP v1.2.1 patches. Before installing SSP, ensure that the following items are installed on your PC: Renesas e 2 studio ISDE v5.4.0 (download from Renesas Gallery GNU ARM Compiler (included in Renesas e 2 studio ISDE v5.4.0 installer) To install the SSP, follow these steps: 1. Download the following items for the SSP Release from Synergy Gallery: SSP_Distribution_1.2.1.zip (SSP Package Installer, including SSP Package, readme_ssp.txt) Renesas Synergy Software Package (SSP) v1.2.1 Release Note 2. Unzip the package and run the SSP_Distribution_1.2.1.exe installer. 3. Install the SSP in the root folder of a compatible e 2 studio installation. Note: The default installation folder for the SSP is C:\Renesas\e2_studio. The SSP documentation installs by default to ~Renesas\Synergy\SSP Documentation. You can change the default location during the installation. The following documents will be installed: readme_ssp.txt (critical information and last-minute updates) R11UT0017EU0104 Rev.1.04 Page 10 of 53

13 7. Changes from SSP v1.2.0 to SSP v1.2.1 release 7.1 Updated Features SSP Quality and Performance Issue ID: 8380 Improvements were made to the flash error ISR to properly clear the interrupt request bits in the event of a flash error. Applies to: r_flash_hp The interrupt request bit is cleared earlier in the LVD ISR to ensure subsequent LVD events are not missed. Applies to: r_lvd The error bits are cleared in the error ISR by performing only a write, instead of a read-modify-write, which had the potential for losing an error event. This could have occurred if another error flag was set after reading the error register, and before writing back the modified value. In the error ISR, the interrupt request bit is cleared after the source is cleared in the peripheral to ensure multiple interrupts are not processed for the same error event. Applies to: r_rspi The interrupt request bits are cleared earlier in the RXI and TXI ISRs to ensure subsequent I2C events are not missed. Applies to: r_sci_i2c sf_el_ux Issue ID: 7913 Fixed the data integrity Issue caused due to resetting the USB FIFO access width for next transfer while the DMA is still doing the data transfer for previous transfer. This ensures data integrity when doing read-write operation via FileX. The fix also enables the double buffer mode for USB Read Pipe which will increase the USB read throughput (FileX Read) while reading files from a mass storage device r_lpmv2 Issue ID: 8040 The idle loop in the TX port now correctly ensures that only "sleep" low power mode will be used when the WFI instruction is executed within the idle loop. The user's application code will no longer need to revert the low power mode to sleep to ensure the TX idle loop does not execute WFI with a low power mode other than sleep Auto Initialization Issue ID: 7879 The XML configuration now allows users to enable or disable auto initialization. Applies To: All supported Synergy MCU Groups. R11UT0017EU0104 Rev.1.04 Page 11 of 53

14 8. Summary of bug fixes since SSP v Crypto/r_sce Issue ID: 8189, 7958 An application interface header file r_arc4_api that provides ARC4 cryptographic functionality is added to r_sce component. Low-level ARC4 cryptographic functions are now available in this release. However there are certain known issues that could cause incompatibility and have been noted in the Known issues section of this document (Issue ID: 8710). Applies To: S7G2, S5D9 Known Limitation: The API function arc4process() has a limitation where the parameter num_bytes must be a multiple of 16. A buffer overflow may occur if other values are used. 8.2 GUIX Studio Issue ID: 7641 GUIX Studio (~ v ) generated "GX_sprite_MEMBERS_DECLARE", instead of "GX_SPRITE_MEMBERS_DECLARE", into one of the auto-generated code "xxx_specifications.h". The Issue resulted in a build error if a GUIX Studio project had a sprite on the top window. The Issue is now fixed in GUIX Studio v5.3.3 resulting in correct generation of Macro and code compilation. Applies to: S7G2, S5D9, S3A7 8.3 NetX, NetxDuo Issue ID: 6390 NetX 5.9 SP2 and NetX Duo 5.10 SP2 are integrated in the SSP The version includes the bug fix to compile NetX or NetX Duo with TraceX enabled. Now NetX or NetX Duo are compiled with TraceX enabled. Applies to: S7G2, S5D9 8.4 NetX App Layer Properties Issue ID: nx_ftp_common Fixed timeout period. It was originally being multiplied by 10 thus making it 10 times the expected value nx_dhcp Because of the design changes in NetX DHCP client, the following options have been removed. For details, see Renesas/Express logic NetX DHCP Client user manual 1 - Packet allocate timeout 2 - Clear queue packets support 3 - ARP probe wait time (seconds) 4 - Server message check interval (unit = processing interval) Because of the design changes in NetX DHCP client following options have been added. For details, see Renesas/Express logic NetX DHCP Client user manual 1 - Maximum DHCP client state record on an interface 2 - Wait before restarting the configuration process (seconds) 3 - ARP probe count 4 - Maximum ARP probe wait time (seconds) 5 - Minimum ARP probe wait time (seconds) 6 - ARP probe wait time (seconds) R11UT0017EU0104 Rev.1.04 Page 12 of 53

15 8.4.3 nx_dhcp_server Because of the design changes in NetX DHCP server, the following options have been removed. For details, see Renesas/Express logic NetX DHCP Server user manual 1 - Server IPv4 address 2 - Subnet Mask for clients 3 - Subnet router IPv4 address 4 - Subnet DNS IPv4 address 5 - Maximum client identifier length 6 - Client IP address lease time 7 - Size of array for holding available IP addresses 8 - Server option list (required) 9 - Size of the DHCP header Because of the design changes in NetX DHCP server following options have been added. For details, see Renesas/Express logic NetX DHCP Server user manual 1 - Slow periodic timer interval to check IP lease expiration 2 - Size of the server host name buffer 3 - Client IP address default lease time The following properties have been modified. For details, see Renesas/Express logic NetX DHCP Server user manual 1 - "Fast periodic timer interval to check valid sessions (ticks)" is now "Fast periodic timer interval to check session inactivity timeout (seconds)" 2 - "Next Client message wait (ticks)" is now "DHCP Client Session timeout - multiple of Fast periodic interval (seconds)" 3 - "Size of the array containing current requested options (units)" is now "Size of the array to contain options in client request (units)" 4 - "Size of the current client hostname buffer" default value 30 changed to nx_dns Because of the design changes in NetX DNS, the following options have been added. For details, see Renesas/Express logic NetX DNS user manual. 1 - Socket fragmentation option The following properties have been modified. For details, see Renesas/Express logic NetX DNS user manual. 1 - "Packets in DNS packet pool" default value 6 changed to "Packet allocate timeout" default value 2 changed to nx_ftp_server Because of the design changes in NetX FTP server, the following options have been added. For details, see Renesas/Express logic NetX FTP server user manual. 1 - Internal thread time slicing interval The following properties have been modified. For details, see Renesas/Express logic NetX FTP server user manual. 1 - "Duration for initial timeout" is now "Socket retransmit timeout" 2 - "Maximum retries per packet" is now "Number of socket retransmissions" R11UT0017EU0104 Rev.1.04 Page 13 of 53

16 3 - "Duration internal services will suspend for (seconds)" default value 100 ticks changed to 1 second (Effectively unchanged) 4 - "Binary left shift as multiplier for retry duration" is now "Binary left shift as multiplier for next retry duration" 5 - "Duration allowed with no activity" fixed. Was originally being multiplied by 10 thus making it 10 times the expected value nx_http_server Because of the design changes in NetX http server, the following options have been added For details, see Renesas/Express logic NetX HTTP server user manual. 1 - Internal thread time slicing interval nx_telnet_server The following properties have been modified. For details, see Renesas/Express logic NetX Telnet server user manual. 1 - "Timeout check period (seconds)" property now accepts values in seconds. Default changed from 600 ticks to 60 seconds, which is same duration 2 - "Client inactivity timeout (seconds)" fixed timeout period. It was originally being multiplied by 10 thus making it 10 times the expected value nx_tftp_server Because of the design changes in NetX TFTP server, the following options have been removed. For details, see Renesas/Express logic NetX TFTP server user manual. 1 - TFTP server activity timeout enable 2 - Server activity time out The following properties have been modified. For details, see Renesas/Express logic NetX TFTP server user manual. 1 - "Timeout check period" is now "Client request activity timeout check interval" nxd_ftp_common Fixed timeout period. It was originally being multiplied by 10 thus making it 10 times the expected value nxd_bsd Warnings added, can also be enabled/disabled nxd_dhcp Because of the design changes in NetX Duo DHCP client, the following options have been removed. For details, see Renesas/Express logic NetX Duo DHCP or DHCPv6 Client user manual. 1 - Packet allocate timeout (seconds) 2 - Clear queue packets support 3 - ARP probe wait time (seconds) 4 - Server message check interval (unit = processing interval) Because of the design changes in NetX Duo DHCP client, the following options have been added. For details, see Renesas/Express logic NetX Duo DHCP or DHCPv6 Client user manual. 1 - Maximum DHCP client state record on an interface R11UT0017EU0104 Rev.1.04 Page 14 of 53

17 2 - Wait before restarting the configuration process (seconds) nxd_dhcp_server Because of the design changes in NetX Duo DHCP server, the following options have been removed. For details, see Renesas/Express logic NetX Duo DHCP or DHCPv6 server user manual. 1 - Server IPv4 address 2 - Subnet Mask for clients 3 - Subnet router IPv4 address 4 - Subnet DNS IPv4 address 5 - Maximum client identifier length 6 - Client IP address lease time 7 - Size of array for holding available IP addresses 8 - Server option list (required) 9 - Size of the DHCP header Because of the design changes in NetX Duo DHCP server, the following options have been added. For details, see Renesas/Express logic NetX Duo DHCP or DHCPv6 server user manual. 1 - Slow periodic timer interval to check IP lease expiration 2 - Size of the server host name buffer 3 - Client IP address default lease time 4 - Vendor assigned unique ID 5 - Private vendor ID 6 - Size of Vendor ID buffer (bytes) The following properties have been modified. For details, see Renesas/Express logic NetX Duo DHCP or DHCPv6 server user manual. 1 - "Fast periodic timer interval to check valid sessions (ticks)" is now "Fast periodic timer interval to check session inactivity timeout (seconds)" 2 - "Next Client message wait (ticks)" is now "DHCP Client Session timeout - multiple of Fast periodic interval (seconds)" 3 - "Size of the array containing current requested options (units)" is now "Size of the array to contain options in client request (units)" 4 - "Size of the current client hostname buffer" default value 30 changed to nxd_dns Because of the design changes in NetX Duo DNS client following options have been added For details, see Renesas/Express logic NetX Duo DNS user manual. 1 - Socket fragmentation option The following properties have been modified. For details, see Renesas/Express logic NetX Duo DNS user manual. 1 - "Packets in DNS packet pool" default value 6 changed to "Packet allocate timeout (seconds)" default value 2 changed to nxd_ftp_server Because of the design changes in NetX Duo FTP Server, the following options have been added. R11UT0017EU0104 Rev.1.04 Page 15 of 53

18 For details, see Renesas/Express logic NetX Duo FTP server user manual. 1 - Internal thread time slicing interval The following properties have been modified. For details, see Renesas/Express logic NetX Duo FTP server user manual. 1 - Limitation fixed: login_function/logout_function can be defined as NULL 2 - "Duration for initial timeout" is now "Socket retransmit timeout" 3 - "Maximum retries per packet" is now "Number of socket retransmissions" 4 - "Duration internal services will suspend for (seconds)" default value 100 ticks changed to 1 second which is essentially same duration 5 - "Binary left shift as multiplier for retry duration" is now "Binary left shift as multiplier for next retry duration" 6 - "Duration allowed with no activity (seconds)" fixed the duration. It was originally being multiplied by 10 thus making it 10 times the expected value nxd_http_server Because of the design changes in NetX Duo HTTP Server, the following options have been added For details, see Renesas/Express logic NetX Duo HTTP server user manual. 1 - Internal thread time slicing interval 2 - Maximum client user name length 3 - Maximum client user password length nxd_nat The following properties have been modified. For details, see Renesas/Express logic NetX Duo NAT user manual. 1 - "Timeout for translation entry (ticks)" is now "Timeout for translation entry (seconds)" nxd_telnet_server The following properties have been modified. For details, see Renesas/Express logic NetX Duo Telnet server user manual. 1 - "Timeout check period (seconds)" Property now accepts values in seconds. Default changed from 600 ticks to 60 seconds which is same duration 2 - "Client inactivity timeout (seconds)" fixed timeout period. It was originally being multiplied by 10 thus making it 10 times the expected value nxd_tftp_server Because of the design changes in NetX Duo TFTP Server, the following options have been removed For details, see Renesas/Express logic NetX Duo TFTP Server user manual. 1 - TFTP server activity timeout enable 2 - Server activity time out (ticks) The following properties have been modified. For details, see Renesas/Express logic NetX Duo TFTP Server user manual. 1 - "Timeout check period (ticks)" is now "Client request activity timeout check interval (ticks)" tx_src Because of requirements in NetX Duo BSD, the following options have been added. R11UT0017EU0104 Rev.1.04 Page 16 of 53

19 For details, see Renesas/Express logic NetX Duo BSD user manual. 1 - TX_THREAD_EXTENSION_3 8.5 nx_ftp_client, nx_ftp_server, nx_http_server, nx_tftp_server, nxd_ftp_client, nxd_ftp_server, nxd_http_server, nxd_tftp_server, fx Issue ID: 8065, 7924 XMLs are updated to fix the warnings. 8.6 r_adc Issue ID: 8072 The ADC infoget function has been updated to return the right address of the voltage and temperature sensor result registers when those channels are configured for use. This information is primarily used by the DTC to automatically transfer data when a conversion is complete. Issue ID: 8066 r_adc, r_agt and r_cac modules now does not have any warnings in configurator generated code. Function prototype is added in auto generated code to avoid compiler warnings. Issue ID: 8354 The PGA is enabled out of reset on the S5D9 which sets ADC Unit 0 channels 0, 1, 2, 5, 6, 16, 17, Voltage and ADC Unit 1 channels 0,1,2,5,6,16, Voltage to differential mode operation which prevents their use as normal single input channels. The driver was updated to explicitly disable the Programmable Gain Array (PGA) instead of relying on default reset state, which is different on some MCUs. Applies to: S7G2, S5D9 8.7 r_agt Issue ID: 8016 The timer period of AGT driver can now generate periods greater than 2 seconds if LOCO/SUBCLK is used as clock source. 8.8 r_cac Issue ID: 7790 When specifying 'External' as the CAC reference clock e 2 studio will now generate the correct configuration, correctly setting the reference clock to External. Issue ID: 8352 When using the CAC module in interrupt mode with a configured callback, the user will receive only 1 callback as expected for each (the same) CAC interrupt. 8.9 r_can Issue ID: 5989 R11UT0017EU0104 Rev.1.04 Page 17 of 53

20 Documentation updated to list CAN S-124 support 8.10 r_crc Issue ID: 7911 Hardware lock was moved from the CRC open() call to the calculatecrc() call to allow multiple upper level layers to use the driver without having to close and reopen each time. While using the CRC driver with this change, note that even though multiple upper layers can use the CRC module without closing and reopening the driver, since the polynomial and bit-order are set in the open() call, all users must use the same polynomial and bit-order for the CRC calculation 8.11 r_ctsu Issue ID: 8059 r_ctsu tuning xml updated to include dependencies (dtc and r_ctsu). This only applies when creating your own tuning project r_flash_lp Issue ID: 7492 The Flash LP module now automatically detects when Blank Checks are spanning Flash macro boundaries and subsequently breaks the request into multiple requests. There is no longer any additional user action required for blank checking. Applies to: S3A r_gpt Issue ID: 7954 Earlier the gpt_instance_ctrl_t control block was allocated on the stack (uninitialized), so the timer might operate in one shot mode event if periodic mode is selected during configuration. Now the code has been modified. The timer operates in the mode which is selected during the configuration r_icu Issue ID: 8364 If an ICU channel is configured for level detection and an interrupt is triggered, there is potential for the interrupt request to not get cleared. This would result in the immediate interrupt trigger and the user would receive a callback for this interrupt. This is due to the interrupt request bit being cleared before the user callback was called at which point the application could clear the source. The interrupt flag clearing sequence is updated to clear the source in the peripheral before clearing the IR bit. This change will eliminate spurious interrupts 8.15 r_kint Issue ID: 8358 The KINT module could have lost a KINT event if a KINT event was generated in between the KINT channels being read and the KINT channels being cleared in the KINT ISR. The user callback is called in between the reading and clearing of the KINT channels. If, for example, a KINT event occurred while the user callback was being executed, that event would be lost. This has been fixed by having the KINT ISR only clear the KINT channels that have been serviced. Using the previous example, the user would now receive a new callback for KINT once the previous KINT ISR had completed. R11UT0017EU0104 Rev.1.04 Page 18 of 53

21 8.16 r_lvd Issue ID: 8005 Only the register settings and configurations of the LVD peripheral have been tested using the IAR toolchain. The GCC toolchain was used for the manual tests with varying voltage as well as for the register settings and configurations of the LVD peripheral r_qspi Issue ID: 5515 QSPI Issue of setting up all unused bits to a known value is addressed in this release. Applies to: S7G2, S5D9, S3A r_riic Issue ID: 7995 In IIC and SCI I2C with DTC, the maximum possible data transfer size in a single transaction is 64 KBytes, transfer using more than 64 KBytes data size should be split into multiple transactions. This restriction does not apply to CPU transfer mode. Applies To: All supported Synergy MCU Groups. Issue ID: 7715 If an I2C error interrupt or transmission end interrupt was triggered then there was potential for the interrupt request to not be cleared. This would result in the interrupt triggering again immediately. The user would not receive a callback for this interrupt. There was no negative impact, but it was unnecessary. This was due to the interrupt source not being cleared in the peripheral before attempting to clear the interrupt request bit. This would occur if the transaction ended with a restart. This has been fixed r_sdmmc Issue ID: 8363 The SDMMC card detect ISR was not clearing the interrupt request bit properly. This would result in the interrupt triggering again immediately. The user would not receive a callback for this interrupt, and there was no negative impact, but it was unnecessary. This was due to the interrupt source not being cleared in the peripheral before attempting to clear the interrupt request bit. The SDMMC SDIO ISR was not clearing the interrupt request bit properly. This would result in the interrupt triggering again immediately. The user would receive an additional callback for this interrupt. There was no negative impact, but it was unnecessary. This was due to the interrupt source not being cleared in the peripheral before attempting to clear the interrupt request bit. Interrupt flag clearing sequence is updated to clear the source in the peripheral before clearing the IR bit. This change will eliminate spurious interrupts Applies to: S7G2, S5D9, S3A7 Issue ID: 8119 The r_sdmmc module only supports 4-byte aligned transfers of 4 or multiples of 4 bytes. All other transfer lengths and alignments should be avoided. Applies to: S3A7, S5D9, S7G2 Issue ID: 6118 r_sdmmc driver does not support MMC card. R11UT0017EU0104 Rev.1.04 Page 19 of 53

22 8.20 r_spi Issue ID: 8112 The RSPI module configuration in the threads tab was showing wrong Tx transfer (DTC) activation source (Software activation instead of TX Interrupt), this has been corrected in this release sf_el_gx Issue ID: 8044 Previously, the SF_EL_GX _gx_synergy_jpeg_draw function could fail to draw the JPEG image if there is a timeout due to the Synergy internal bus system being too busy to finish JPEG hardware rendering. The error resulted in a JPEG rendering abort and could cause screen corruption in a frame buffer. To fix this, timeout is extended from 1 tick to 1000 ticks. Issue ID: 8061 Previously, the properties "Name of Display Driver Run-time Configuration", "Name of Frame Buffer A" and "Name of Frame Buffer B" had to be amended by users manually. Those are now inherited from the dependent module 'Display Driver on r_glcd' automatically so users do not need to input the names by hand. Notes: 1. A dependency between "GUIX Port on sf_el_gx" and "Display Driver on r_glcd" is now automatically resolved, so properties "Name of Display Driver Run-time Configuration", "Name of Frame Buffer A", and "Name of Frame Buffer B" are obsolete in the "GUIX Port on sf_el_gx" component. Conversely, the new configuration property "Display Driver Configuration Inheritance" is added to provide users two options: "Inherit Graphics Screen 1" (default) and "Inherit Graphics Screen 2". 2. When a user project is upgraded to use SSP v1.2.1, the default option will be applied to the "Display Driver Configuration Inheritance" property. Therefore, the dependency between "GUIX Port on sf_el_gx" and "Display Driver on r_glcd" is to be resolved by inheriting names for GLCDC Graphics Screen 1. With this, any existing user applications which use GLCDC Graphics Screen 1 would not require any action with SSP v However, any existing user applications which use GLCDC Graphics Screen 2 will need to select "Inherit Graphics Screen 2" option to resolve the dependency by inheriting name of Frame buffer or name of Display runtime configuration for GLCDC Graphics Screen 2. Issue ID: 7693 GUIX alpha blending did not work for the 8-bpp Glyph drawing if the 2DG engine (D/AVE 2D) is used. The Issue was that the alpha value setting was missing in the SF_EL_GX _gx_dave2d_glyph_8bit_draw function. The Issue was fixed and now GUIX alpha rendering works correctly with the 2DG engine sf_el_nx Issue ID: 8365 The Ethernet IR bit was being cleared before the source was cleared in the peripheral. This would lead to duplicate interrupts as the IR bit cannot be cleared until the interrupt is first cleared in the peripheral. The Ethernet ISR would not perform any processing on the duplicate interrupt, but it was a waste of cycles. The IR bit is now cleared after clearing the source in the peripheral. Issue ID: 8082 R11UT0017EU0104 Rev.1.04 Page 20 of 53

23 Chained packet reception caused code to get stuck in a while() loop in the receive interrupt of the Ethernet driver (sf_el_nx). This halted the program execution. This was applicable in any project using a packet pool with packet size smaller than the largest packet that could be received. This Issue has been fixed. Issue ID: 8071 NetX Port driver was configured PHY LSI in External Loop-back mode by default, which was not a supported mode. Therefore, this configuration was removed from the initialization sequence of the driver. Issue ID: 8068 Ethernet throughput on PK-S5D9 and SK-S7G2 boards was less than half the theoretical maximum (less than 50 Mbps) supported by the synergy EMAC. This was caused by an incorrect timing parameter used for the communication between the MAC and PHY on these boards. The ethernet driver is updated to configure the correct timing parameter for SK-S7G2 and PK-S5D9 to achieve the required throughput (around 94 Mbps). The root cause on how this timing parameter affects is to be determined. As a result, the timing parameter may have to be fine-tuned for boards other than the ones tested. Applies to: S7G2, S5D sf_el_nx_comms Issue ID: 7411 In the Thread Stacks pane under the Threads tab, sf_el_nx_comms Communication Framework component previously came up with two NetX port components incorrectly. Now one of them is removed as expected sf_el_tx Issue ID: 5921 The idle loop in the TX port now correctly ensures that only "sleep" low power mode will be used when the WFI instruction is executed within the idle loop. The user's application code will no longer need to revert the low power mode to sleep to ensure the TX idle loop does not execute WFI with a low power mode other than "sleep" sf_el_ux Issue ID: 8209, 8289 Modifying USB FIFO access width during a read or write operation caused data corruption in the USB FIFO. This is now resolved by the revised USB FIFO access code. In addition to the Issue fix, the driver code is updated to be able to handle data transfer even though a user buffer was not aligned to 32-bit or 16-bit memory boundary. Issue ID: 8055 The driver support FIFO size for Bulk OUT transfer from default 512 bytes to a maximum of 2048 bytes. User can configure the FIFO size in the Property window of the USBX host class block in the XML configurator. This improves the USB data throughput for the write operation for larger transfer size and reduces the number of transfer descriptors creation in a transfer request as the FIFO size increases. Issue ID: 7576 R11UT0017EU0104 Rev.1.04 Page 21 of 53

24 The USB VBUS pin could be wrongly controlled to Active Low even though the "VBUSEN pin Signal Logic" property of USBX Port HCD on sf_el_ux for USBxS component is configures to "Active High". Now the Issue was resolved and USBX Port driver works as expected. Issue ID: 7560 Manual test was failing in SSP b.1 due to bug in sf_el_ux module (which is fixed in release 1.2.0) and also the major changes in the XML of the sf_el_ux module. Now the manual test is migrated to SSP pack with small code changes in manual test and tested module. Applies to: S7G2, S5D sf_el_ux_comms Issue ID: 7860 The USBX Port driver was previously not functional with DTC and failed in the driver initialization. Now the Issue is resolved and USBX Port driver works correctly with DTC sf_message Issue ID: 4694 The parameter checking used to pass even if the p_buffer pointer is not in the block pool. The code has been modified, the parameter checking returns an error if p_buffer pointer address is not at the start address of any block and between the start and end address of the block pool. Applies to: S7G2, S5D9, S3A sf_touch_panel_i2c Issue ID: 7795 SX8654 Touch chip driver had un-necessary delay in SX8654_i2c_read, SX8654_i2c_write or SX8654_i2c_write_followed_by_read. Now the delay is removed and the driver works fine with SCI I2C or RIIC HAL driver being used underneath of it. Applies to: S7G2, S5D Synergy Tools Issue ID: 5408 For S7G2 and S5D9 MCUs, the name for the PFS Register Write Enable bit has been renamed to correctly match the documentation, as is the case with other MCUs. This has no impact on SSP code as that bit field is never referenced. If a user application has code that referenced that bit field directly, then the code would need to be changed to reference the new bit field name. Specifically: IO uint8_t PSFWE : 1; /*!< PFS Register Write Enable */ has been renamed to: IO uint8_t PFSWE : 1; /*!< PFS Register Write Enable */ Applies to: S7G2, S5D USBX Device Development Issue ID: 7410 One of the configuration properties in the "USBX Interface Configuration Mass Storage Class" component had a typo but now was corrected as below. Incorrect: "Interface Number of Communications Class interface" Correct: "Interface Number of Bulk-Only Data Interface" R11UT0017EU0104 Rev.1.04 Page 22 of 53

25 8.31 ux Issue ID: 8076, 7597 USBX Device class CDC-ACM works in windows 10 PC (host PC), if the class code property is set to Device(0x00) or Miscellaneous(0xEF) in Synergy Configuration tool, otherwise it does not work. The windows 7 PC (host PC) works fine with the above-mentioned class code and also with class code property set to Communications (CDC). Applies To: All supported Synergy MCU Groups XML Configurations Issue ID: 7811, 5531 Synergy Frameworks with Init functions are now provided the support for user to choose whether to initialize from the auto generated code. Added an option in xml code to enable or disable the auto initialization. Applies to: S7G2, S5D9, S3A7, S BSP Issue ID: 7826 For both S7G2 and S5D9 MCUs, the system will now correctly insert SRAM wait states only when the System ICLK requires it. Applies to: S7G2, S5D9 Issue ID: 7794 When creating an SSP project and choosing "Custom User Board (Any Device)" as the board type, building the generated project will no longer produce a build warning XML License File Issue ID: 8521 An updated evaluation license xml file that allows Wifi/Cellular/BLE framework compilation/build for these framework components is included in this release. Installing this SSP patch release will copy the new evaluation license file to the <eclipse_install_folder>\internal\projectgen\arm\licenses folder. Applies To: All supported Synergy MCU Groups r_sci_i2c Issue ID: 8531, 8526 The sci_i2c open() routine was updated to initialize internal control structures before using them in the driver (the uninitialized control block caused interrupt 0 in the NVIC to be disabled). Applies To: All supported Synergy MCU Groups sf_spi Issue ID: 7815 SPI Framework Device configurator has been updated in this release. This will resolve the limitations in the previous version of SPI Framework Device configurator. Following are the major updates: 1. Resolved the Issues due to the use of multiple lower level configurations on the same bus. 2. Only one Lower level device need to be configured for multiple Framework Device configurations. 3. There is no need to mention the type of lower level driver used by the Framework (RSPI/SCI). R11UT0017EU0104 Rev.1.04 Page 23 of 53

26 4. Fixed the build error when connecting multiple SPI Framework Devices on the same channel (Eliminates the need to add a preprocessor macro for each SPI Framework Device instance on the bus). Backward compatibility of the existing configuration is maintained. When upgrading the existing projects with the new version, the existing SPI Framework Configuration will appear with a tag [SUPERSEDED] on the module name. This means, the old configurations will continue to be supported as SUPERSEDED modules till the next minor release and this may be changed to DEPRECATED state after that. This configuration will be deprecated in the subsequent minor/major release. It is recommended to moving to the updated SPI Framework Shared Bus implementation found under Framework/Connectivity. If a [SUPERSEEDED] configuration is used, follow these points. 1. For each SPI Framework Device, the corresponding SPI Driver associated to it should also be configured. 2. For example when configuring SPI framework device g_sf_spi_device0, add a SPI Driver like g_spi0 (r_sci_spi/r_rspi) and configure required lower level configurations like phase, polarity, bitrate etc of the device linked to it. Each SPI Framework Device in the application should be configured like this. 3. When configuring the Framework Shared Bus, the channel number should be configured with the channel number to which the device has been connected; this channel will be used for the lower level configuration. The channel configured in the SPI Driver configuration underneath the Framework Device will be overridden by the channel configured in the bus. 4. The type of low level driver used by the SPI Framework should be configured correctly in the Framework Shared Bus configuration (i.e. SCI SPI or RSPI). 5. Each SPI Framework Device should be configured separately for DTC/non-DTC use. If the user wishes to use DTC for all SPI Framework Devices then each device should have DTC filled in underneath the SPI Driver sf_i2c Issue ID: 7813 I2C Framework Device configurator has been updated in this release. This will resolve the limitations in the previous version of I2C Framework Device configurator. Following are the major updates: 1. Resolved the Issues due to the use of multiple lower level configurations on the same bus. 2. Only one Lower level device need to be configured for multiple Framework Device configurations. 3. There is no need to mention the type of lower level driver used by the Framework (RIIC/SCI). 4. Fixed the build error when connecting multiple I2C Framework Devices on the same channel (Eliminates the need to add a preprocessor macro for each I2C Framework Device instance on the bus). Backward compatibility of the existing configuration is maintained. When upgrading the existing projects with the new version, the existing I2C Framework Configuration will appear with a tag [SUPERSEDED] on the module name. This means, the old configurations will continue to be supported as SUPERSEDED modules till the next minor release and this may be changed to DEPRECATED state after that. This configuration will be deprecated in the subsequent minor/major release. It is recommended to moving to the updated I2C Framework Shared Bus implementation found under Framework/Connectivity. If a [SUPERSEEDED] configuration is used, follow these points: 1. All I2C Framework Devices on the same bus must use the same lower level configuration settings (i.e. I2C Driver) except for the slave address and addressing mode. The framework will use the configuration of the first device that it opens in the application to configure the bus. This means that all I2C Framework Devices on the same bus must have the same lower level configuration settings (except for the slave address and addressing mode). If different configurations are used, then proper operation cannot be guaranteed. I2C Framework code internally switches the devices by switching the slave address using the slaveaddressset() function. 2. In order to use the DTC, the first device that the application opens should be configured with DTC. Figuring out which device is opened first can be difficult to figure out sometimes in a threaded application so it is recommended to configure all the lower level devices with DTC or non-dtc for ease of use. By default all the drivers will be added with DTC. 3. The type of low level driver used by the I2C Framework should be configured correctly in the Framework Shared Bus configuration (i.e. SCI I2C or RIIC). R11UT0017EU0104 Rev.1.04 Page 24 of 53

27 4. When configuring the Framework Shared Bus, the channel number should be configured with the channel number to which the device has been connected; this channel will be used for the lower level configuration. The channel configured in the I2C Driver, underneath the I2C Framework Device, will be overridden by the channel configured in the bus r_cgc Issue ID: 8057 A project generated for the S7G2-DK or S7G2 HMI boards will have the r_cgc Main Oscillator Clock Source incorrectly set to 'Crystal or Resonator'. The proper setting for these boards should be 'External Oscillator'. Workaround: Subsequent to creating an application for either of these boards, navigate to the g_cgc CGC Driver on r_cgc in the HAL/Common Stacks window. In the properties for that driver, change Main Oscillator Clock Source to 'External Oscillator' r_lpmv2 Issue ID: 8194 This is only relevant to applications using Software Standby, Software Standby with Snooze, or Deep Software Standby. The DSB instruction (data synchronization barrier) has been added and will execute immediately prior to WFI instruction (sends MCU to low power mode). Without the DSB instruction, reads from and writes to memory, peripheral registers, or buses may not complete before entering low power mode, if the low power mode is Software Standby, Software Standby with Snooze, or Deep Software Standby, some clocks are stopped while in low power mode, so the writes may not complete before the clocks are stopped. The DSB instruction forces all outstanding memory operations to complete. However, it is not possible in all cases to prevent the possibility that reads and writes to memory (RAM or peripheral or otherwise) may be interrupted if an interrupt or thread swap occurs after the DSB instruction executes but before the WFI instruction executes. This should only be an Issue if the peripheral or bus clocks are running substantially slower than the main system clock r_fmi Issue ID: 8048 Unique ID can be returned on all MCUs that have valid on-chip factory flash. R11UT0017EU0104 Rev.1.04 Page 25 of 53

28 9. Known Issues and limitations in SSP v1.2.1 that were identified since SSP v1.2.0 release. 9.1 r_rspi Issue ID: 8193 In the RSPI driver, the BRDV register value is set to 0, this prevents RSPI from being used with baud rates lower than 235 kbps at the default PCLKA. Workaround: The work around is to use the higher baud rates that is supported by the slave device. 9.2 ux Issue ID: 8397 The USBX enumeration thread could cause stack overflow if the default configuration (1 KB) is applied for 'Stack size for USBX threads' build-time option (UX_THREAD_STACK_SIZE). Users can configure the stack size by changing the USBX Source component property through Synergy Configurator. Users to be notified that the USBX pre-built library was statically built with the default configuration (1 KB) so users need to use the USBX Source component to configure the stack size. Workaround: Use the USBX Source module and change "Stack size for USBX threads" property from the default value (1024 in bytes) to greater number such as sf_el_ux Issue ID: 8428 Users need to set 'requested_length' of the USBX Device CDC API ux_device_class_cdc_acm_read large enough to accommodate expected reception data length. If the length of reception data from a USB Host is larger than 'requested_length', the API returns UX_SUCCESS but reception data will not be stored in a user buffer and 'actual_length' is set to '0'. Applies To: All supported Synergy MCU Groups. Workaround: Set 'requested_length' of the USBX Device CDC API ux_device_class_cdc_acm_read large enough to accommodate the expected reception data length. Issue ID: 8518 Even while DMA transfers are enabled, SF_EL_UX Host Controller Driver (HCD) performs software copy for USB data read if a user buffer is not aligned to 32-bit memory boundary. Because of this implementation, USB data throughput would be reduced if a user buffer is not aligned to 32-bit memory boundary. Applies To: S7G2, S5D9 Workaround: Not required (USB transfer functions but it is recommended to align a user buffer to 32-bit memory boundary for better data throughput). 9.4 sf_jpeg_decode Issue ID: 8487 SF_JPEG_DECODE module misses to include configuration header file named sf_jpeg_decode_cfg.h, which includes a build-time option SF_JPEG_DECODE_CFG_PARAM_CHECKING_ENABLE. Because of this, the module APIs never check the input parameter even though the build-time option enabled in the configuration header file. Applies To: S7G2, S5D9 Workaround: To enable the parameter, check for SF_JPEG_DECODE module, define SF_JPEG_DECODE_CFG_PARAM_CHECKING_ENABLE in the compiler preprocessor. 9.5 nx Issue ID: 8504 R11UT0017EU0104 Rev.1.04 Page 26 of 53

29 The name of DHCP Client is given as i.e. "g_dhcp_client0 DHCPv4" through Synergy Configurator, which is with a space character. Although the name is not required by most DHCP Servers, the name should be changed to one without a space character since RFC 2132 specifies that a host name shall not contain a space character. This Issue will be fixed in the future SSP release. Applies To: All supported Synergy MCU Groups. Workaround: If the name with a space could be an Issue, modify the auto-generated code in <xxxx>_thread.c to remove the space in the DHCP Client host name. g_dhcp_client0_err = nx_dhcp_create (&g_dhcp_client0, &g_ip0, "g_dhcp_client0 DHCPv4"); For instance, change "g_dhcp_client0 DHCPv4" to "g_dhcp_client0_dhcpv4". To work around this Issue, follow the procedural steps below. 1. Copy /src/synergy_gen/framework/<xxxx>_thread.c, which has code shown above to /src/ directory in a Synergy Project. 2. Highlight /src/synergy_gen/framework/<xxxx>_thread.c in the Project Explorer pane on the e2 studio. 3. Right click on the file and select Exclude from build. 4. Select All and click OK. Now the original driver code is excluded from build and the file copied to /src/ is to be compiled. 5. Make a change to remove a space in the name of DHCP Client host name in /src/<xxxx>_thread.c. Issue ID: 8559 Packet pool is not allocating appropriate memory while creating packet pool. Consequently user can utilize some but not all of the packet memory allocated. Applies To: All supported Synergy MCU Groups. Workaround: Packet pool module misses out allocating memory for packet header of each packet. This can be circumvented by allocating those many extra bytes in "Packet Size in Bytes" field. For NetX packet header size with default configuration is 52 and NetX Duo is 60. Thus add 52 to "Packet Size in Bytes" to originally intended value for this field. For NetX Duo use 60 instead of 52. NOTE: 52 and 60 are values with default configuration for NetX and NetX Duo source. For any other configuration, confirm and use, size of NX_PACKET. 9.6 r_sci_i2c Issue ID: 7946 SCI I2C in IRQ mode may not work with certain slave devices, you need to enable DTC transfer mode in order to work with such devices. Workaround: Use DTC transfer mode when using SCI I2C driver. 9.7 GUIX integration Issue ID: 8000 Customer will get a compiler warning [-Wimplicit-function-declaration] if they use either of API listed below in their application code because the function prototypes are missing in gx_api.h. gx_multi_line_text_button_text_id_set gx_multi_line_text_button_text_set gx_multi_line_text_view_char_index_set Workaround: No special workaround required for the functionality but users can add the API prototype in application code to resolve the compiler warning. R11UT0017EU0104 Rev.1.04 Page 27 of 53

30 Issue ID: 8037 GUIX and SF_EL_GX (GUIX Port) do not work if ThreadX timer tick is set to 1ms if hardware graphics accelerators (DRW and JPEG) are enabled. Workaround: Use GUIX and 2DG or JPEG hardware accelerators with setting ThreadX tick time to 10ms (default setting). 9.8 r_sci_uart Issue ID: 8043 On SK-S7G2 board, it is observed that the initial few bytes of data is getting corrupted when transmitted over UART. This is observed only in the debug mode on the SK-S7G2 board only. Applies to: SK-S7G2 Workaround: When this issue occurs, do a soft reset from the debugger and run again. 9.9 Synergy Software Configurator Issue ID: 8047 Using the e 2 studio 'cut and paste' feature to move a configured module stack from one thread to another thread (in the same project) on the Threads tab doesn t work if you cut it, and then paste it in the project configuration. Users will experience build errors because the selected SSP modules are removed from the project in the 'cut' operation', but not added again in the 'paste' operation. Workaround: Copy the module stack, paste it to the new location, and then delete it from the original location r_gpt_input_capture Issue ID: 8060 r_gpt_input_capture cannot be used without r_gpt. Workaround: When using r_gpt_input_capture, make sure r_gpt is checked on the Components tab to avoid build errors r_gpt_input_capture, r_lpm Issue ID: 6236 When two instances of the GPT capture driver are defined for the same channel and they are opened in sequence without closing the first instance, the second instance will fail to open and first instance will malfunction. Workaround: The following workarounds are possible: 1. When two instances of GTP capture drivers are used, use separate channel for each instance. 2. If both the instances use the same channel number, then close the first instance before opening the second one. Issue ID: 6108 Return value of versionget function will be SSP_ERR_ASSERTION if the parameter p_version is NULL. Workaround: The user must take into account the reserved bits in the Module stop registers when using the mstpcrset function. The user can call mstpcrget and either AND or OR the bits of the module they want to start or stop and then pass in that value. R11UT0017EU0104 Rev.1.04 Page 28 of 53

31 9.12 r_lpm, r_lpmv2 Issue ID: 6670 Before applying a user specified configuration, the code checks to see if the options are valid for the current MCU. The list of options that are checked are a superset containing features that are not present on all Synergy MCUs. There is no functional impact from these redundant checks. Workaround: None 9.13 sf_el_gx Issue ID: 8469 A GUIX application might experience screen tearing (information from multiple frames in a single screen draw) on the LCD panel during the screen update if D/AVE 2D rendering is enabled. The SF_EL_GX might toggle the frame buffer before D/AVE 2D rendering is done. This is visible as screen tearing if it occurs. Applies To: S7G2, S5D9 Workaround: Use software rendering if screen tearing is observed. The root cause of D/AVE 2D not finishing the drawing at the time of frame buffer toggling is now under investigation and should be fixed in future SSP version sf_el_ux_comms Issue ID: 8216 SF_EL_UX_COMMS_V2 Open function would cause timeout if the USB CDC-ACM enumeration was done earlier than the semaphore UX_COMMS_SEMAPHORE being created in the Open function. In the case, the semaphore is never signaled in USBX CDC instance_activate callback function and Open function continues to suspend until timeout occurred. Workaround: Add following code block in tx_application_define_user. Note that the name of Comms instance is given as 'g_sf_comms0'. if (NULL!= g_sf_comms0.p_ctrl) { sf_el_ux_comms_instance_ctrl_t * p_ux_comms_ctrl = (sf_el_ux_comms_instance_ctrl_t *) g_sf_comms0.p_ctrl; /* Check if the semaphore for g_sf_comms0 is ready. */ if (0x53454D41!= p_ux_comms_ctrl->semaphore.tx_semaphore_id) { tx_semaphore_create (&p_ux_comms_ctrl->semaphore, (CHAR *) "UX_COMMS_SEMAPHORE", 0); } } 9.15 sf_audio_playback Issue ID: 8220 Audio playback framework do not support pause-resume functionality. Workaround: To start the audio play again, stop the current play and restart the audio play again. Issue ID: 8219 Call to unlock() function with an argument passed as SF_COMMS_LOCK_ALL does not releases a mutex for read and write. Hence the UART communication port does not work in multiple Threads, only single Thread is supported. Applies to: All the Synergy MCU group R11UT0017EU0104 Rev.1.04 Page 29 of 53

32 Workaround: To use the communication port in other Threads, call the unlock() function twice, first call with the argument passed as SF_COMMS_LOCK_TX and second time with argument as SF_COMMS_LOCK_RX sf_external_irq Issue ID: 8287 In the external IRQ framework module, the callback is handled internally by the framework code. The callback field in the lower level HAL driver properties will not be used by the framework. Hence this filed does not need to be configured. Currently, this callback field is editable in the ISDE, and the value written in this field will be overridden by the framework callback. This will not have any impact to the functionality of the module. Workaround: None 9.17 sf_el_fx Issue ID: 8569 Adding two "FileX on Block Media" instances in the Synergy Configurator causes duplicated symbol error in the autogenerated code when compiled. Applies To: All the Synergy MCU group Workaround: Modify the auto-generated code (common_data.c) by hand. To work around this Issue, follow the procedural steps below. 1. Copy /src/synergy_gen/common_data.c to /src/ directory in a Synergy Project. 2. Highlight /src/synergy_gen/framework/common_data.c in the Project Explorer pane on the e 2 studio. 3. Right click on the file and select Exclude from build. 4. Select All and click OK. Now original common_data.c, which is auto-generated by Synergy Configurator is excluded from build and the file copied to /src/ is to be compiled. 5. Make following changes in /src/common_data.c. 6. Found typedef for struct st_sf_block_media_format, which defines sf_block_media_format_t type structure. 7. Put following code on top of typedef. This is for excluding second emitted type definition. #ifndef BLOCK_MEDIA_FORMAT_STRUCT_ #define BLOCK_MEDIA_FORMAT_STRUCT_ 8. Put #endif right after the typedef for sf_block_media_format_t. You would have following code block after followed Step 1 ~ #ifndef BLOCK_MEDIA_FORMAT_STRUCT_ #define BLOCK_MEDIA_FORMAT_STRUCT_ typedef struct st_sf_block_media_format { } sf_block_media_format_t; #endif Found following local variable definitions in the auto-generated code. ssp_err_t error; uint32_t fx_ret_val; R11UT0017EU0104 Rev.1.04 Page 30 of 53

33 5. Put following code on top of local variables. This is for excluding second emitted variable definition. #ifndef MEDIA_OPEN_VARS_ #define MEDIA_OPEN_VARS_ 6. Put #endif right after the local variable definition. You would have following code block after followed Step 4 ~ #ifndef MEDIA_OPEN_VARS_ #define MEDIA_OPEN_VARS_ ssp_err_t error; uint32_t fx_ret_val; #endif sf_spi Issue ID: 8529 In the SPI Framework, before using the Lock function, use the same device instance to perform an Open, Read or Write operation. This will configure the lower level bus with device configurations that is used in the Lock function. All other functions reconfigure the bus with the current instance of the device. This issue will be fixed in the next release. Applies To: All supported Synergy MCU Groups. Workaround: Call the Lock function just after opening the device instance or before calling any other device instances. Example: //Open Device0 g_sf_spi_device0.p_api->open(); //Call Lock API for Device0.This should be called before accessing any other device g_sf_spi_device0.p_api->lock(); If any other device is called after opening Device0 (from above example), perform a read or write and then call the lock API. //Use Device0 for read/write, then use Lock API for Device0 g_sf_spi_device0.p_api->read() g_sf_spi_device0.p_api->lock(); //Then initiate the transfer for Device Crypto/r_sce Issue ID: 8710 The ARC4 cryptographic function was removed from SSP v1.2.0 since it was not usable in any of the earlier releases of SSP. The function has been added back to SSP in this release. However the APIs for this module have changed in order to resolve the functional issues affecting the module and rendering it unusable. For a description of new APIs and usage note for the redesigned function please refer to the Appendix I: ARC4at the end of this Release Note. The data type of the input parameter(s) in customer facing API(s) are changed: 1. In Release1.2.0, control structure and config structure types are cipher_ctrl_t and cipher_cfg_t. In SSP v1.2.1 these control and config structures types are changed to arc4_ctrl_t and arc4_cfg_t. 2. Function R_SCE_ARC4_2048Encrypt() has been renamed to R_SCE_ARC4_Process (). A new function, R_SCE_ARC4_KeySet(), has been provided as an interface to specify the initial key set. R11UT0017EU0104 Rev.1.04 Page 31 of 53

34 Workaround: Users who might have used R_ARC4_2048Encrypt() function will need to manually migrate any existing user application that uses this API to the modified interface specified in r_arc4_api.h API header file and the associated data structures specified in this interface header file. Issue ID: 8384 The function R_SCE_StatusGet() does not indicate the hardware initialization status as documented. Applies To: All supported Synergy MCU Groups. Workaround: Use the return code from the function g_sce_crypto_api.open() to determine whether the initialization is performed File System Issue ID: 8409 Projects using FileX do not build if TraceX is enabled. This is because the trace elements are not defined in the FileX source files. Workaround: Define TX_ENABLE_EVENT_TRACE as a C compiler preprocessor option in your Synergy project. To define the macro, go to Project menu > Properties > C/C++ Build > Settings > Tool Settings > Cross ARM C Compiler > Preprocessor. Add TX_ENABLE_EVENT_TRACE in 'Defined symbols (-D)' list. (This is the case for ARM GNU tool chain) r_sci_spi Issue ID: 8590 When using SCI SPI with DTC enabled, the callback function should be used (set the callback function in the modules configuration property). Passing a NULL callback may create an exception. Applies To: All supported Synergy MCU Groups. Workaround: The work around is to use a callback function when DTC transfer is enabled r_riic Issue ID: 8565 In RIIC, the Zero bytes data or address byte only transfer doesn't work in DTC mode, it works fine in IRQ mode. Applies To: All supported Synergy MCU Groups. Workaround: Work around is to use IRQ mode to transfer zero bytes data or address bytes only. Remove DTC module from the configurator of RIIC module r_crc Issue ID: 7781 In SSP v1.2.0 and the CRC module can be used by only one application thread/process at a time. If another process wants to call the module, then the first process must close the CRC driver so that the next one can open it. For instance, any existing Flashloader and Bootloader projects will not work with the v1.2.0 or CRC module if both internal and external versions of sf_firmware_image are used in the same project. Applies To: All supported Synergy MCU Groups. Workaround: To use Bootloader and Flashloader, choose v1.2.0-b1 version of the CRC module from the components tab in ISDE 9.24 SSP XMLs for ISDE Issue ID: 8503 Selecting a 48 or 36 pin package version of the S124 MCU will generate a project that fails to build and wrongly displays property information that pertains to the S5D9 MCU. This will be fixed in the next SSP release Applies To: S124, 36- and 48-pin package types. R11UT0017EU0104 Rev.1.04 Page 32 of 53

35 Workaround: Instead of a 64-KB device, select one of the 128-KB superset devices for the project. The following device options could be selected: R7FS124773A01CFL: 48-LQFP, 128 KB R7FS124773A01CNE: 48-QFN, 128 KB R7FS124772A01CLM: 36-LGA, 128 KB Note: Developers should ensure that code size should not exceed 64 KB Hardware Issue ID: 7619 When using RS-232 on the PE-HMI board, pin PB6 is incorrectly configured as ETH WOL pin which is not used on this board. To successfully use RS-232 it needs to be set as a standard GPIO - active High. Workaround: RS-232 transmit will not function without pin configuration change. Change the ETHERC1.RMII WOL pin configuration to None. Change the PB06 pin configuration to Output mode (Initial High). R11UT0017EU0104 Rev.1.04 Page 33 of 53

36 10. Additional Usage Notes for SSP v ux Issue ID: 8269 Currently user application is required to always use XML auto-generated helper functions fx_media_init_functionn or ux_system_host_storage_fx_media_get. However this would not work for all projects. If the project did not use either of these functions, USBX thread suspends forever to wait for ux_host_storage_semaphore_media_init_done signaled in ux_system_host_storage_change_function. Workaround: Use fx_media_init_functionn in user application code, or use ux_system_host_storage_fx_media_get in the user callback function from ux_system_host_change_function to signal the semaphore ux_host_storage_semaphore_media_init_done. Issue ID: 8541 Following build-time configurations are applied to X-Ware pre-built libraries which are listed under each configuration in this SSP release version. Because of the configuration difference, these pre-built libraries might behave different from the source modules (which are built and tested with default build-time configurations). The configurations below are subject to change in the future SSP release and could be changed to the default value in future SSP releases, provided there is no exception with using the default build configurations. 1. USBX (applies to S7, S5 and S3 MCU group (Cortex-M4)) UX_THREAD_STACK_SIZE: 2048 (default:1024 defined in ux_port.h) Applies to: Device HID, Device Mass Storage, Host Mass Storage pre-built libraries UX_SLAVE_REQUEST_DATA_MAX_LENGTH: 1024 (default:4096 defined in ux_port.h) Applies to: Device CDC-ACM, Device Mass Storage pre-built libraries UX_HOST_CLASS_STORAGE_MEMORY_BUFFER_SIZE: 8096 (default:4096 defined in ux_host_class_storage.h) Applies to: Host Mass Storage pre-built library 2. USBX (applies to S1 MCU series (Cortex-M0+)) UX_SYSTEM_DEVICE_ONLY: Defined Applies to: USBX pre-built library UX_THREAD_STACK_SIZE: 512 (default:1024 defined in ux_port.h) Applies to: Device HID, Device Mass Storage pre-built libraries UX_SLAVE_REQUEST_DATA_MAX_LENGTH: 512 (default:4096 defined in ux_port.h) Applies to: Device CDC-ACM, Device Mass Storage pre-built libraries 3. The other X-Wares: Other X-ware libraries are built using default configurations in ISDE. Workaround: Use source module instead of pre-built library if any build-time configuration shown above does not match to your system configuration. Issue ID: 8550 Maximum Power Consumption configuration for a USB Device is limited to 100mA, which is incorrect for USB2.0 spec (500mA is allowed). Applies To: All the Synergy MCU group. R11UT0017EU0104 Rev.1.04 Page 34 of 53

37 Workaround: Edit the bmaxpower value in the USB Configuration Descriptor manually. The configuration is autogenerated in common_data.c by Synergy Configurator. To work around this Issue, follow the procedural steps below. 1. Copy /src/synergy_gen/common_data.c to /src/ directory in a Synergy Project. 2. Highlight /src/synergy_gen/framework/common_data.c in the Project Explorer pane on the e 2 studio. 3. Right click on the file and select Exclude from build. 4. Select All and click OK. Now original common_data.c, which is auto-generated by Synergy Configurator is excluded from build and the file copied to /src/ is to be compiled. 5. Make a change to bmaxpower configuration in /src/common_data.c sf_el_ux Issue ID: 7998 Testing was conducted with O2 compiler optimization option only, -O3 testing has not been conducted. All projects are currently running with -O2 optimization, so please use the -O2 optimization for the USB MSC Host project Workaround: None Issue ID: 8455, 8574 Current SF_EL_UX HCD driver does not enable Double Buffer feature for Bulk OUT PIPEs, which is supported by USB hardware. Because of that, USB data throughput for Data Write through a Bulk OUT PIPE is expected to be less than 12MBps. This Issue is only for Data Write (Bulk OUT) but double buffering is supported for Data Read (Bulk IN). Applies To: S7G2, S5D9, S3A7 Workaround: Not applicable Issue ID: 5944 USB X driver build with -O3 optimization will not function Workaround: USB X module are tested with compiler optimization level -O2 (in case of GCC). USB X module will not work properly if built with optimization level -O3. Please use optimization level to O GUIX integration Issue ID: 8085 Users cannot show a pixelmap image in a GUIX Drop List automatically. Workaround: To show a pixelmap in a GUIX drop list, set a pixelmap by gx_drop_list_pixelmap_set() after the status of the drop list became to GX_STATUS_VISIBLE r_cgc Issue ID: 8164 The CGC properties do not offer the necessary functionality to get a callback when an Oscillation Stop Detect event occurs. This functionality must be manually added by the user. Workaround: Add the following code to the user application. /* Prototype the callback function */ void my_osc_stop_callback(cgc_callback_args_t * p_args); R11UT0017EU0104 Rev.1.04 Page 35 of 53

38 void hal_entry(void) { /* Enable the Osc Stop Detect functionality */ g_cgc.p_api->oscstopdetect( my_osc_stop_callback, true ); /* Osc Stop Detect is an NMI interrupt. Enable the NMI in ICU */ R_ICU->NMIER_b.OSTEN = 1; } /* Create a CGC Osc Stop Detect callback. void my_osc_stop_callback(cgc_callback_args_t * p_args) { /* Do Oscillation Stop Detect Processing */ } 10.5 sf_el_gx Issue ID: 8195 Pixelmap rotation function is not supported for 2DG rendering. Current GUIX version only supports the function with software rendering. Workaround: Use software rendering (Uncheck 'Enable 2D Drawing Engine' option in the GUIX Synergy Advanced Settings, and Set 'No' to the 'Enable Synergy 2D Drawing Ending Support' property of 'GUIX on gx' component in the Synergy Configurator) if the Pixelmap rotation function needs to be used in a GUIX application NetX Issue ID: 8543 BSD module does not explicitly warn about enabling 'Extended Notify Support' in NetX and NetX Duo source which is disabled by default. This causes bsd_initialize to fail. Workaround: Enable 'Extended Notify Support' in NetX or NetX Duo source. Issue ID: 8544 NetX SNTP NX_SNTP_CLIENT_MAX_ROOT_DISPERSION option is not provided in configuration window thus user cannot configure it from configuration window. Workaround: User can configure this value by defining it in ISDE cross compiler's preprocessor options as NX_SNTP_CLIENT_MAX_ROOT_DISPERSION=<value> 10.7 Code Cleanup Issue ID: 8350 When creating a Synergy project based on the 'Blinky' or 'Blinky w/ ThreadX' project templates, customers may notice unnecessary rebuilding of auto-generated source files within their projects. For example, when a user creates a Synergy C Project for the DK-S124 board and the Blinky project template and then builds the project. If they then modify just the source file src/hal_entry.c and build the project, the auto-generated source file src/synergy_gen/hal_data.c is unnecessarily rebuilt. Workaround: None 10.8 sf_el_fx Issue ID: 7324 The I/O driver communicates the success or failure of the request through the fx_media_driver_status, member of FX_MEDIA. R11UT0017EU0104 Rev.1.04 Page 36 of 53

39 p_fx_media->fx_media_driver_status will be having the value of FX_PTR_ERROR when a) NULL value is set to p_fx_media->fx_media_driver_info, member of FX_MEDIA. or b) NULL value is set to p_el_fx->p_lower_lvl_block_media, member of block Media Control Block. User manual does not have this information. Applies To: S7G2, S5D9, S5D9, S3A7 Workaround: None 10.9 r_rtc Issue ID: 8370 A drift in RTC value is observed after every device reset. This drift is around one second after every three resets. Applies To: All supported Synergy MCU Groups. Workaround: Applications that resets more often is recommended to use the following update in the RTC driver code. Update driver code to avoid unconditional reset of the start bit in the r_rtc_set_clock_source function. Example: if(0 == HW_RTC_CounterStartStopBitGet(p_rtc_reg) { /* Set the START bit to 0 */ error = r_rtc_start_bit_clear(p_rtc_reg); } r_adc Issue ID: 8375 If parameter checking is disabled from the default configuration, the R_SCI_UartBaudSet API in SCI UART may not work properly. Also the application will generate unused parameter warnings for some modules Applies To: All supported Synergy MCU Groups. Workaround: It is recommended to keep the parameter checking enabled to avoid these issues r_qspi Issue ID: 6709 In QSPI driver, if the Page program API is called without calling open function, it will exhibit undefined behavior that may include the function not returning back to the caller. Workaround: None Crypto/r_sce Issue ID: 8152 Triple DES counter mode encryption functionality is not implemented. Invoking g_tdes192ctr_on_sce.encrypt() or g_tdes192ctr_on_sce.decrypt() return an error code that indicates the functionality is not available. Applies To: S7G2, S5D9, S3A7 Workaround: None r_ctsu Issue ID: 8226 The CTSU unit on the S5D9 is identical to the one on the S7G2 where it provides the expected functionality. However, since the S5D9 has not been explicitly tested for CTSU operation, there may be unknown functionality limitations. Applies To: S5D9 Workaround: None R11UT0017EU0104 Rev.1.04 Page 37 of 53

40 10.14 sf_power_profiles Issue ID: 8027 The module has not yet been through the complete test process for S124, there may be unknown functional limitations. Applies To: S124 Workaround: None R11UT0017EU0104 Rev.1.04 Page 38 of 53

41 11. Complete list of modules available in this release Module Name SSP Feature Supported Synergy MCU Groups HAL Driver bsp Board Support Package S124, S3A7, S5D9, S7G2 r_adc A/D Converter S124, S3A7, S5D9, S7G2 r_agt Asynchronous General Purpose Timer S124, S3A7, S5D9, S7G2 r_cac Clock Frequency Accuracy Measurement S124, S3A7, S5D9, S7G2 Circuit r_can Controller Area Network S124, S3A7, S5D9, S7G2 r_cgc Clock Generation Circuit S124, S3A7, S5D9, S7G2 r_crc Cyclic Redundancy Check calculator S124, S3A7, S5D9, S7G2 r_ctsu Capacitive Touch Sensing Unit S124, S3A7, S5D9, S7G2 r_dac Digital to Analog Converter S124, S3A7, S5D9, S7G2 r_dmac Direct Memory Access Controller S3A7, S5D9, S7G2 r_doc Data Operation Circuit S124, S3A7, S5D9, S7G2 r_dtc Data Transfer Controller S124, S3A7, S5D9, S7G2 r_elc Event Link Controller S124, S3A7, S5D9, S7G2 r_flash_hp Flash Memory, High Performance S5D9, S7G2 r_flash_lp Flash Memory, Low Power S124, S3A7 r_fmi Factory Microcontroller Information S124, S3A7, S5D9, S7G2 r_glcd Graphics LCD Controller S5D9, S7G2 r_gpt General Purpose Timer S124, S3A7, S5D9, S7G2 r_gpt_input_capture General Input Capture S124, S3A7, S5D9, S7G2 r_icu Interrupt Controller Unit S124, S3A7, S5D9, S7G2 r_ioport General Purpose I/O Ports S124, S3A7, S5D9, S7G2 r_iwdt Independent Watchdog Timer S124, S3A7, S5D9, S7G2 r_jpeg_decode JPEG Decode S5D9, S7G2 r_kint Keyboard Interrupt Interface S124, S3A7, S5D9, S7G2 r_lpm Low Power Mode S124, S3A7, S7G2 r_lpmv2_s124 Low Power Mode V2 for S124 S124 r_lpmv2_s3a7 Low Power Mode V2 for S3A7 S3A7 r_lpmv2_s5d9 Low Power Mode V2 for S5D9 S5D9 r_lpmv2_s7g2 Low Power Mode V2 for S7G2 S7G2 r_lvd Low Voltage Detection Driver S124, S3A7, S5D9, S7G2 r_pdc Parallel Data Capture Unit S7G2 r_qspi Quad Serial Peripheral Interface S3A7, S5D9, S7G2 r_riic IIC S124, S3A7, S5D9, S7G2 r_riic_slave IIC Slave S124, S3A7, S5D9, S7G2 r_rspi Serial Peripheral Interface S124, S3A7, S5D9, S7G2 r_rtc Real-time Clock S124, S3A7, S5D9, S7G2 r_sce Secure Crypto Engine (TRNG, AES, RSA, S124, S3A7, S5D9, S7G2 TDES, HASH, DSA, ARC4) r_sci_i2c Serial Communication Interface I2C S124, S3A7, S5D9, S7G2 r_sci_spi Serial Communication Interface SPI S124, S3A7, S5D9, S7G2 r_sci_uart Serial Communication Interface UART S124, S3A7, S5D9, S7G2 r_sdmmc SDHI driver for SDIO and SD/MMC memory S3A7, S5D9, S7G2 devices r_slcdc Segment LCD Controller S3A7 R11UT0017EU0104 Rev.1.04 Page 39 of 53

42 r_ssi (Inter-IC Sound) interface [old: Serial Sound S3A7, S5D9, S7G2 Int.] or r_i2s r_wdt Watchdog Timer S124, S3A7, S5D9, S7G2 Synergy Framework sf_adc_perodic Periodic Sampling ADC S124, S3A7, S5D9, S7G2 sf_audio_playback Audio Playback S124, S3A7, S5D9, S7G2 sf_audio_playback_hw_dac Audio Playback HW DAC S124, S3A7, S5D9, S7G2 sf_audio_playback_hw_i2s Audio Playback HW I2S S3A7, S5D9, S7G2 sf_audio_record_adc Audio Record ADC S3A7, S5D9, S7G2 sf_block_media_sdmmc Block Media Interface for SD Multi Media Card S3A7, S5D9, S7G2 sf_console Console S124, S3A7, S5D9, S7G2 sf_el_fx Synergy FileX Interface S3A7, S5D9, S7G2 sf_el_gx Synergy GUIX Interface S5D9, S7G2 sf_el_nx Synergy NetX Interface S5D9, S7G2 sf_el_nx_comms Synergy NetX Communication Interface S5D9, S7G2 sf_el_ux Synergy USBX Interface S124, S3A7, S5D9, S7G2 sf_el_ux_comms Synergy USBX Communication Interface S124, S3A7, S5D9, S7G2 sf_el_ux_comms_v2 Synergy USBX Communication Interface V2 S124, S3A7, S5D9, S7G2 sf_external_irq External Interrupt Framework S124, S3A7, S5D9, S7G2 sf_i2c I2C Framework S124, S3A7, S5D9, S7G2 sf_jpeg_decode JPEG Decode S5D9, S7G2 sf_message Inter-Thread Messaging S3A7, S5D9, S7G2 sf_power_profiles Power Mode Profile S124, S3A7, S7G2 sf_spi SPI Framework S124, S3A7, S5D9, S7G2 sf_tes_2d_drw 2D Drawing Engine Framework S5D9, S7G2 sf_thread_monitor Thread Monitor (Watchdog) S3A7, S5D9, S7G2 sf_touch_ctsu Capacitive Touch Sensing Unit S124, S3A7, S5D9, S7G2 sf_touch_ctsu_button Capacitive Touch Sensing Unit Button S124, S3A7, S5D9, S7G2 sf_touch_ctsu_slider Capacitive Touch Sensing Unit Slider S124, S3A7, S5D9, S7G2 sf_touch_panel_i2c Touch Panel I2C S5D9, S7G2 sf_uart_comms UART framework S124, S3A7, S5D9, S7G2 X-Ware Stacks fx FileX S124, S3A7, S5D9, S7G2 gx GUIX S5D9, S7G2 nx NetX S5D9, S7G2 nx_auto_ip NetX Auto IP S5D9, S7G2 nx_bsd NetX BSD S5D9, S7G2 nx_dhcp_client NetX DHCP Client S5D9, S7G2 nx_dhcp_server NetX DHCP Server S5D9, S7G2 nx_dns_client NetX DNS Client S5D9, S7G2 nx_ftp_client NetX FTP Client S5D9, S7G2 nx_ftp_server NetX FTP Server S5D9, S7G2 nx_http_client NetX HTTP Client S5D9, S7G2 nx_http_server NetX HTTP Server S5D9, S7G2 nx_pop3 NetX POP3 S5D9, S7G2 nx_ppp** NetX PPP** S5D9, S7G2 nx_smtp_client NetX SMTP Client S5D9, S7G2 nx_sntp_client NetX SNTP Client S5D9, S7G2 nx_telnet_client NetX Telnet Client S5D9, S7G2 R11UT0017EU0104 Rev.1.04 Page 40 of 53

43 nx_telnet_server NetX Telnet Server S5D9, S7G2 nx_tftp_client NetX TFTP Client S5D9, S7G2 nx_tftp_server NetX TFTP Server S5D9, S7G2 nxd NetX Duo Stack S5D9, S7G2, nxd_auto_ip NetX Duo Auto IP S5D9, S7G2 nxd_bsd NetX Duo BSD S5D9, S7G2 nxd_dhcp NetX Duo DHCP IPv4 Client S5D9, S7G2 nxd_dhcp NetX Duo DHCP IPv6 Client S5D9, S7G2 nxd_dhcp_server NetX Duo DHCP IPv4 Server S5D9, S7G2 nxd_dhcp_server NetX Duo DHCP IPv6 Server S5D9, S7G2 nxd_dns NetX Duo DNS Client S5D9, S7G2 nxd_ftp_client NetX Duo FTP Client S5D9, S7G2 nxd_ftp_server NetX Duo FTP Server S5D9, S7G2 nxd_http_client NetX Duo HTTP Client S5D9, S7G2 nxd_http_server NetX Duo HTTP Server S5D9, S7G2 nxd_nat NetX Duo NAT S5D9, S7G2 nxd_pop3 NetX Duo POP3 S5D9, S7G2 nxd_ppp** NetX Duo PPP** S5D9, S7G2 nxd_smtp_client NetX Duo SMTP Client S5D9, S7G2 nxd_sntp_client NetX Duo SNTP Client S5D9, S7G2 nxd_telnet_client NetX Duo Telnet Client S5D9, S7G2 nxd_telnet_server NetX Duo Telnet Server S5D9, S7G2 nxd_tftp_client NetX Duo TFTP Client S5D9, S7G2 nxd_tftp_server NetX Duo TFTP Server S5D9, S7G2 tx ThreadX S124, S3A7, S5D9, S7G2 ux_device_class_storage USBX Device Class Mass Storage S124, S3A7, S5D9, S7G2 ux_device_class_hid USBX Device Class HID S124, S3A7, S5D9, S7G2 ux_device_class_cdc_acm USBX Device Class CDC-ACM S124, S3A7, S5D9, S7G2 ux_host_class_cdc_acm USBX Host Class CDC-ACM S5D9, S7G2 ux_host_class_storage USBX Host Class Mass Storage S5D9, S7G2 ux_host_class_hid USBX Host Class HID S5D9, S7G2 ux_host_class_hub USBX Host HUB S5D9, S7G2 Note: * These NetX and NetX Duo Application Layer protocols are MCU-independent software modules that have been tested only on Synergy S7G2 MCU Group devices. However, these protocols rely on underlying NetX and NetX Duo networking stacks that have been tested on S7G2 as well as S5D9 MCU Group devices, hence are identified as supported in this table. ** The NetX Application Layer modules listed below are not currently supported in the Synergy Configuration tool. To experiment with these NetX Application Layer modules, go to the Components tab of the Synergy Configuration tool (configuration.xml), and select the NetX Application Layer module: nx_ppp: Refer to the NetX Point-to-Point Protocol (PPP) User Guide nxd_ppp: Refer to the NetX Duo Point-to-Point Protocol (PPP) User Guide The USBX class modules listed below are experimental software modules within the SSP that have not yet been completely tested, and are currently not supported by Synergy Configuration tools. Use of these modules in customer projects is not supported by Renesas at this time. Experimental Modules ux_device_class_cdc_ecm USBX Device Class CDC-ECM S124,S3A7,S5D9,S7G2 ux_device_class_rndis USBX Device Class RNDIS S124,S3A7,S5D9,S7G2 ux_host_class_gser USBX Host Class Generic Serial S3A7, S5D9,S7G2 R11UT0017EU0104 Rev.1.04 Page 41 of 53

44 ux_host_class_printer USBX Host Class Printer S3A7, S5D9,S7G2 ux_host_class_prolific USBX Host Class Prolific S3A7, S5D9,S7G2 ux_host_class_swar USBX Host Class Swar S3A7, S5D9,S7G2 ux_network_driver USBX Network Driver S124,S3A7,S5D9,S7G2 R11UT0017EU0104 Rev.1.04 Page 42 of 53

45 12. Additional Technical Notices All SSP modules are tested using the default configuration settings in the e 2 studio, operation of the modules with other configurations are not guaranteed. Subscribe to the Synergy Technical Bulletin Board to receive the latest technical news and notifications about new features, known issues, workarounds, and release announcements. To subscribe, visit Sign in to Renesas Rulz, and press Subscribe to this forum. Additional technical information, including informative papers and articles on SSP and Synergy can be found at Synergy Knowledge Base, R11UT0017EU0104 Rev.1.04 Page 43 of 53

46 13. Appendix I: ARC SCE ARC4 Driver Usage Guide Crypto Interface The SCE ARC4 Driver is implemented on r_sce_arc4 and provides primitive cryptographic operations for ARC4 cryptographic algorithm. This section describes how to configure the SCE Driver using the e 2 studio ISDE and how to include API functions in your application. In the Project Configurator in the e 2 studio ISDE, you can add and configure a SCE Driver Module in the Modules pane of the Threads tab by selecting New > Driver > Crypto and selecting the desired cryptographic submodule. To access cryptographic API functions of the R_SCE module, use the Crypto Interface API implemented as R_SCE. Figure 1 shows the driver architecture for the crypto module. Figure 1 Crypto Block Diagram What Does the SCE ARC4 Module Do? This driver provides the following crypto primitive functions: ARC4 encryption and decryption operations for the key specified Table 1 ARC4 Key Size S7G2, S5D9 S3A7 S124 Notes ARC4 - Key Sizes supported 8 bytes to 256 bytes, multiples of 4-bytes N/A N/A ARC4 algorithm Getting Ready to Write a Crypto Application The driver is integrated into the Synergy Software package. In e 2 studio, you can choose a board and create a project for your application. During the configuration of the project, add the component r_sce to the application Using e 2 studio to write an ARC4 Crypto Application The arc4 crypto driver is integrated into the e 2 studio ISDE. See How to use e 2 studio in the SSP User s Manual. The following cryptographic algorithms are available for configuration through this interface: ARC4 module In e 2 studio, create and configure a project and add the drivers: 1. Create the project: See Creating a Synergy Project 2. Configure the project: See Configuring a Project 3. Add the drivers: See Adding Drivers to a Thread and Configuring the Drivers The following resources are required for an application that use the ARC4 Crypto Driver with SCE: R11UT0017EU0104 Rev.1.04 Page 44 of 53