C.1. Troubleshooting steps

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

  1. 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 which during runtime attempts to branch to an address that is not in the axf file. Remove any self-modifying code and try hardware profiling again.

      Note

      There is an exception to this. the ARM Profiler does allow self-modifying code that installs handlers at addresses 0x0 to 0x1C at run time.

      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

      The ARM Profiler can only profile hardware up to 350 MHz on the core clock. If your development board runs faster than this, 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 uses an inverted clock, make sure the 'Inverted clock' setting is used in your RVConfig file.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

    Note

    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

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. If your .apa 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.

    Note

    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.

  12. 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)

    Note

    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, 2008 ARM Limited. All rights reserved.ARM DUI 0414C
Non-Confidential