C.1. Troubleshooting steps

If you configure your hardware according to the process detailed in chapter two of this User Guide and the image still fails to execute when running through the ARM Profiler, consider the following common causes:

  1. The "ARM Profiler: WARNING: Trace buffer overflow" error message may indicate that the hardware target is running too fast relative to the CPU and disk performance of your development machine. The full live update feature, configurable in the ARM target run configuration window, can slow down the host. Try turning off this option if you receive too many "ARM Profiler: WARNING: Trace buffer overflow" error messages.


    "ARM Profiler: WARNING: Trace buffer overflow" warnings and “ARM Profiler: WARNING: ETM buffer overflow” warnings can lead to bad output like analysis files that cannot be loaded and invalid samples count.

  2. The "ARM Profiler: WARNING: ETM buffer overflow" error message indicates that too much data is trying to pass through the ETM port of the target for the ARM Profiler to handle. Try increasing the port size of the ETM/TPIU, or, for supported targets, use estimated cycles to remove cycle information from the ETM trace. To profile on hardware using estimated cycles, use the Sample Rate drop-down menu to set the sample rate to zero.

    ETM overflows during an ARM Profiler run usually indicate that your target is running so fast that it is swamping the ETM's output buffer with data, causing your target to fail to collect that data. This creates holes in your profile, the severity of which depend on how many overflows occur. Normally these overflows can be resolved by reducing the clock speed of your target processor, but there are cases where reducing the processor speed also reduces the speed of the ETM. In these cases, the reduction of clock speed has no impact on the amount of ETM overflows. Solutions to this problem vary widely from target to target. Contact ARM support for more information.

  3. If the ARM Profiler terminates with the error message that reads "Exiting application due to unrecoverable errors please refer to the ARM Profiler user guide Appendix C hardware troubleshooting guide", one of the following issues is likely the cause.

    • The image file specified in the ARM Profiler launch configuration does not match the image on the target hardware.

      If the image specified in the launch configuration does not match the one loaded on the development board, the image can not run on the target with profiling turned on. This can often happen when using the Symbols Only option, but no specific error is generated in this case. Make sure the image file matches the one on the target and try hardware profiling again.

    • Self-modifying code was used

      The ARM Profiler may fail with the above error if you have self-modifying code that attempts to branch to an address that does not match the behavior in the axf file. Remove any self-modifying code and try hardware profiling again.


      There is an exception to this. The ARM Profiler does allow self-modifying code that installs exception handlers at run time at address offsets 0x0000 to 0x001C.

      The ARM Profiler does not support profiling through certain abort handlers. Some handlers, like the prefetch abort handler, cause failure with the above error message.

    • The hardware target is running too fast

      Try reducing the speed of the hardware for the purpose of profiling and try again.

    • Code contained in the image file is defective

      It is important that you verify your code is stable before running it through the ARM Profiler.

    • If your hardware has delays on the trace port pins, use the Auto-Calibrate feature to center the clock against the data.

  4. Either the RVI or RealView Trace 2 unit may be in a bad state if the ARM Profiler fails with one of the following error messages:

    • "Session handle invalid"

    • "Device state requested on connection could not be achieved"

    • "RVI timed out waiting for a response from the device"

    The RVI or RealView Trace 2 unit may be in a bad state. To fix this, try power cycling the RVI and RealView Trace 2 units. First, power down the development board, followed by the RVI and RealView Trace 2 units. Then, turn the development board back on. Next, restart the RVI and RealView Trace 2 units and wait until the STAT LED on the RVI unit stays on and the Power On LED indicator on the RealView Trace 2 unit is lit. When all of the hardware is up and running again, power cycle the development board again and try another profiling run.

  5. If the ARM Profiler fails with a "No connection to the device" error message, try the following:

    • Make sure that your RVConfig file matches your development board.

    • Check the connections to and from the RVI and RealView Trace 2 units.

    • Make sure both the RVI and hardware target are powered on.

    If all of the above are correct and you still see the "No connection to the device" error, it is possible that the device has not yet obtained an IP address. Try power cycling the RVI unit as described in step two.

  6. The "Corrupted trace" warning message might indicate that your target has imperfect timing characteristics. Try turning on the Auto-Calibrate Timings option in the Connections tab of the launch configuration dialog. For more information on the Auto-Calibrate Timings option, see Auto-calibrate timings and using a TPIU pattern generator.


    You must provide an executable to run Auto-Calibrate. If you choose to run the Dhrystone example, set the iteration count to one billion. This gives the ARM Profiler enough time to complete the auto-calibration of your hardware.

  7. If the ARM Profiler fails with the "Device in use" error message, it may be due to an active RealView Debugger connection to the unit. Only one connection can be used with the RVI and RealView Trace 2 units at a time, so if RVD is already connected, try closing RVD and running the ARM Profiler again. This error can also occur if another instance of the ARM Profiler is already connected to the device. Check to make sure you only have a single instance of the ARM Profiler open.

  8. The "Bad plugin" error message indicates the specified '.rvc' configuration file is not present. Check to make sure the configuration is in the directory location specified in the RealView Trace 2 launch configuration dialog.

  9. The "Failed to parse the specified configuration file" indicates a bad or invalid '.rvc' configuration file. Create a new, valid '.rvc' configuration file and try running hardware profiling again.


    RVConfig files must be created using RVI version 3.3 or greater. RVConfig files created using older versions of RVI are not compatible with the ARM Profiler

  10. The "Buffer overflow" error message may also indicate that the hardware target is running too fast or one of the units is in a bad state. See items one and two for potential fixes for these issues.

  11. If the ARM Profiler fails with the error message "Device not powered or has been disconnected", check the connections and power status of the RVI and RealView Trace 2 units.

  12. The "Error in Loading the Object Image <path> execution terminated" indicates a missing or invalid image file. Make sure the launch configuration dialog points to a valid image file and try hardware profiling again.

  13. The error message "read/write memory failure" might be caused by a bad configuration of the target hardware's memory map. Configure the memory map per your hardware specification to correct this issue.

  14. If your .apd analysis files are being created with zero instructions reported and you are running on a board that requires the use of an inverted clock to capture trace at high speeds, try one of the following fixes:

    • Check to make sure the probe is securely connected to the right slot.

    • If your hardware uses an inverted clock, make sure the Inverted Clock setting is used in your RVConfig file.


    Many settings in the RVConfig, including trace timing settings, are not honored by the ARM Profiler, but the Inverted Clock setting is an exception to this rule.

  15. Some indirect branch errors are caused by an application writing the vector table as part of the bootstrap. Due to limitations in some ARM breakpoint units, only a subset of writes to the vector table can be caught. If your program writes the vector table as part of the setup, make sure that the final write to the vector table occurs at one of the following locations:

    • 0x08 (SVC)

    • 0x18 (IRQ)


    If your application writes the vector table, it is advised that two NOPs are appended after the vector table write to avoid misreporting links in the call chain for certain targets.

If you are having an issue with hardware profiling not listed here, try power cycling the RVI and RealView Trace 2 units as explained above and re-starting hardware profiling.

Copyright © 2007- 2009 ARM Limited. All rights reserved.ARM DUI 0414D