Corstone SSE-300 FVP Simulator Fails to Start in ARM Development Studio

The Corstone SSE-300 Fixed Virtual Platform (FVP) simulator is a critical tool for developers working with ARM Cortex-M55-based systems. However, users often encounter issues when attempting to run the simulator within ARM Development Studio. The primary symptoms include the simulator failing to start, entering a "pending mode," or encountering errors when using functions like printf due to semihosting misconfigurations. These issues can stem from incorrect model parameters, improper path configurations, or semihosting settings. Below, we delve into the root causes and provide detailed troubleshooting steps to resolve these challenges.


Incorrect Model Parameters and Path Configuration

The Corstone SSE-300 FVP simulator relies on specific model parameters and environment configurations to function correctly. A common issue arises when the simulator executable is not properly added to the system path, preventing ARM Development Studio from locating and launching the FVP. Additionally, incorrect or incomplete model parameters can cause the simulator to fail during initialization or enter a pending state.

The model parameters define the configuration of the virtual platform, including CPU features such as the Floating Point Unit (FPU), M-Profile Vector Extension (MVE), and Helium extensions. For example, parameters like -C cpu0.FPU=1 and -C cpu0.MVE=2 enable the FPU and MVE, respectively. However, if these parameters are misconfigured or conflict with the target application, the simulator may fail to start or behave unpredictably.

Another critical aspect is the use of the -I (or --iris-server) option when launching the FVP from the command line. This option enables the Iris server, which allows ARM Development Studio to connect to the running model. Without this option, the simulator may start but remain inaccessible to the debugger, resulting in a pending state.


Semihosting Configuration and printf Functionality Issues

Semihosting is a mechanism that allows ARM-based applications to communicate with the host system for input/output operations, such as printing to the console. When using the Corstone SSE-300 FVP simulator, semihosting must be explicitly enabled to support functions like printf. However, improper semihosting configuration can lead to issues such as the simulator entering pending mode or failing to display output.

The -C cpu0.semihosting-enable=1 parameter is required to enable semihosting in the FVP. Without this parameter, the simulator will not recognize semihosting requests from the application, causing functions like printf to hang or fail silently. Additionally, semihosting must be disabled in the debugger to avoid conflicts with the FVP’s built-in semihosting system. This is achieved by adding a target initialization script with the command set semihosting enabled off.

In some cases, even with semihosting enabled, the printf function may not produce output in the console. This can occur if the output is redirected to a different interface, such as the UART. For example, the Blinky example project uses the UART for printf output, which appears in a separate telnet pane rather than the Target Console. Understanding the output destination is crucial for diagnosing and resolving semihosting-related issues.


Resolving Simulator Pending Mode and Semihosting Configuration

To address the issues described above, follow these detailed troubleshooting steps:

Step 1: Verify FVP Executable Path and Model Parameters

Ensure that the FVP executable is correctly added to the system path. This allows ARM Development Studio to locate and launch the simulator. Verify the path configuration by running the FVP executable from the command line. If the simulator starts successfully, the path configuration is correct.

Next, review the model parameters used to launch the FVP. Use the --list-params option to generate a list of all available parameters and their default settings. Compare these settings with the parameters specified in your project configuration. Ensure that parameters such as -C cpu0.FPU=1, -C cpu0.MVE=2, and -C cpu0.enable_helium_extension=1 are appropriate for your target application.

Step 2: Enable Iris Server and Connect to the Simulator

When launching the FVP from the command line, include the -I (or --iris-server) option to enable the Iris server. This allows ARM Development Studio to connect to the running model. Use the -p option to display the port number used by the Iris server. For example:

./FVP_Corstone_SSE-300 -I --iris-server -p

In ARM Development Studio, connect to the running model by specifying the address and port number (e.g., 127.0.0.1:7100).

Step 3: Configure Semihosting for printf Functionality

To enable semihosting in the FVP, add the -C cpu0.semihosting-enable=1 parameter to the model configuration. This ensures that the simulator recognizes semihosting requests from the application. Additionally, disable semihosting in the debugger to avoid conflicts. Create a target initialization script with the following command:

set semihosting enabled off

This script should be executed immediately upon connecting to the simulator.

Step 4: Verify Output Destination for printf

If the printf function does not produce output in the Target Console, verify the output destination. Some projects, such as the Blinky example, use the UART for printf output. In such cases, the output will appear in a separate telnet pane rather than the Target Console. Use the fwrite function to explicitly write to stdout if necessary.

Step 5: Test with a Known Good Example

To isolate the issue, test the simulator with a known good example, such as the Blinky project included in the CMSIS pack. This helps determine whether the issue is specific to your project or a general configuration problem. If the simulator works with the Blinky project but not your application, review your project settings and code for discrepancies.

Step 6: Update to the Latest Software Versions

Ensure that you are using the latest versions of ARM Development Studio, the CMSIS pack, and the Corstone SSE-300 FVP simulator. Updates often include bug fixes and improvements that resolve known issues. For example, the CMSIS pack version 1.2.0 includes updates specifically for the Corstone SSE-300 FVP.

Step 7: Analyze Debug Logs and Error Messages

Examine the debug logs and error messages generated by the simulator and ARM Development Studio. These logs provide valuable insights into the root cause of the issue. Look for messages related to semihosting, model initialization, and Iris server connectivity. Use this information to refine your configuration and resolve any remaining issues.


By following these steps, you can resolve the most common issues encountered when using the Corstone SSE-300 FVP simulator in ARM Development Studio. Proper configuration of model parameters, semihosting, and output destinations is essential for successful simulation and debugging. Additionally, testing with known good examples and staying up-to-date with software versions ensures a smooth development experience.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *