Skip to main content
Renesas Electronics Europe - Knowledgebase

What do I need to know when porting projects to SSP 1.3.0?

Last Updated:10/18/2017


What do I need to know when porting projects to SSP 1.3.0 from earlier releases?



The SSP 1.3.0 release with feature enhancements and Bug fixes is now available on the Synergy Gallery.  Users can port their existing applications to the latest release from prior SSP releases (1.1.x, 1.2.x). While porting the applications to the latest SSP release, we noticed a few minor issues. These issues and the associated work around are provided in the rest of this document.

  • More memory required: Application projects, while using the SSP 1.3.0, requires more memory (ROM and RAM) compared to previous versions of SSP.  If the previously created applications are not building due to insufficient memory, the u­ser will need to adjust the stack, heap and the buffer sizes in the application projects in order to accommodate the new memory requirements. This will be critical particularly for S1 based projects where the RAM and ROM sizes are limited.


  • Superseded info in the configurator: In some applications, when a previously created project is imported to the latest SSP (1.3.0), the configurator shows the Superseded info in the configurator for some of the SSP components. Here the backward compatibility of the existing configuration is maintained. When upgrading the existing projects with the new version, the existing 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.  From the application perspective the project should compile and work. If the user wants to move to the latest version and configuration this can done by deleting and recreating the SUPERSEDED portion in the configurator.


  • Incompatible GUIX driver and GUIX Studio versions: Some projects which were created using SSP 1.2.0 and ported to SSP 1.3.0 may fail to compile due to the GUIX driver incompatible with the older GUIX studio.  In order to make this compatible, use the GUIX studio version.
    • Open your existing GUIX Studio project (.gxp) with GUIX Studio v5.3.3.7.
    • Go to Configure menu and open the Configure Project window. Set GUIX Library Version to 5.3.3
    • And push the Save button to close the window.
    • Go to Project menu and select Generate All Output Files. No change required on the window so just click the Generate button.
    • Note:  If your SSP project uses GUIX and raw JPEG as the background format, and you experience JPEG decoder crashes when rendering the GUIX background, changing the background format from raw JPEG to native GUIX pixelmap solves the problem.


  • Using IAR: While using IAR for the application development, if the Optimization level is selected as High Balanced Mode, it optimizes the loop code as well. So user need to pay attention on the variable type used for the loop variable. By declaring and using the volatile keyword for the variable related to loop code, application failing due to optimization specific issues can be resolved.


  • Porting GUIX Projects: While porting GUIX projects on PK-S5D9 and SK-S7G2 the user needs to select i2c mode as “Fast Mode” in the configurator. If the Normal mode is selected, the Application won’t run and goes to the default handler.


  • Module description folder: While it is not common to skip the .module description folder in the project, during import of the project, if the project doesn’t contain the. module description folder, importing to SSP 1.3.0 will not be smooth.  In this case, to import the project to SSP 1.3.0 from a previous SSP, the user needs to include the previous SSP pack files in the latest SSP installation folder. The application project without. module descriptions folder need to be opened (configuration.xml) with previous SSP (1.1.x/1.2.X) this generates the .module descriptions folder. Once the project is opened with previous version of the SSP, the SSP version needs to be changed to SSP 1.3.0 using the BSP tab on the configurator. This will convert the application projects from SSP 1.2.0 to 1.3.0 without any issues even in the absence of the .module_descriptions folder. Note that some projects in the SSP 1.3.0 bundle on the Synergy Gallery (like the DHCP Client).


  • GDB process stays sticky even when the e2 studio session is closed: In some instances while testing/debugging an application projects with SSP 1.3.0 and  e2 studio, the GDB process stays sticky which gets instantiated on the PC while running e2 studio. This GDB session needs to be closed gracefully when e2 studio is closed, or when e2 studio is restarted.  If the GDB process is still seen on the windows PC task manager even after e2 studio is closed and restarted then downloading and debugging of the application fails.  In order to overcome this issue, the kill the GDB process from the Windows Task Manager and then start e2 studio.


  • Notes on the Wi-Fi framework based applications: For Wi-Fi Framework based project developed using SSP 1.2.x,

Follow the instructions below for migrating to SSP v1.3.0:

Case 1:  If the Wi-Fi application project uses NSAL and NetX for networking functionality, go to the Wi-Fi thread stack configuration section, add the NetX Network Driver for Wi-Fi (sf_wifi_nsal_nx) as shown in the screenshot.


Then configure the Reset Pin, Chip select pin based on the HW platform for the Wi-Fi module connected over (PMOD) and complete the rest of the upgrade steps described above.


Case 2: If the Wi-Fi application project uses the On-Chip Networking stack, after upgrading to SSP v1.3.0  go to the Wi-Fi thread and recreate the configurator contents based on the SSP1.2.x contents. Ensure all hardware configurations are set up properly based on the SSP1.2.x application project and complete the rest of the upgrade steps.


SSP 1.3.0