When encountering a problem with iSYSTEM hardware or software, read this section before contacting iSYSTEM technical support for help. Provided tips and hints may already resolve the problem.
Below troubleshooting information is valid for all architectures and for all emulation types. Architecture and tool specific troubleshooting information can be found in a specific emulation technical notes document.
When winIDEA workspace is being set up from scratch it's possible that the debug tool fails to connect to the target or it succeeds but the debug session behaves unpredictably. Such behavior can be related to invalid winIDEA settings.
In certain cases when changing the emulator or emulation technique in existing operational workspace, settings in the workspace are reset to the default values. In case of problems, check new workspace settings against the original one.
In case of problems getting up and running the debugger for the first time, it is recommended to use first a pre-built example workspace. Example workspaces for majority of supported architectures and debug tools can be installed from winIDEA Help / Install Examples.
Debug session hangs or becomes unstable
If an unrecoverable error occurs that can't be resolved with a new debug download or debug reset, perform the power cycle in the following order:
1. Turn off the target.
2. Turn off the emulator
3. Wait a second
4. Turn on the emulator
5. Turn on the target
Download (flash programming) fails
If you are downloading the code in the target device flash memory, check that it is not secured. This can happen either intentionally or by accidentally writing to the memory locations managing the flash security levels.
To unsecure the flash memory, go to Hardware menu, select the flash device that you wish to unsecure and select Unsecure command. Note that unsecure command is available only for certain microcontrollers.
Strange CPU behavior due to unintended memory reads
If the CPU starts to behave unpredictably make sure you are not making any unintended memory reads. Memory reads to undefined memory regions may cause the CPU debug to fail. Such issues are most commonly caused by:
- opening Memory window in undefined memory space
- viewing SFR groups for the peripherals, which are not yet enabled
- reading SFRs which affect the CPU just by being read (e.g. interrupt acknowledge registers)
- uninitialized pointer listed in the Watch window
- scrolling through the disassembly window into an undefined memory region
For troubleshooting purposes close all debug windows and see if this resolves the problem. This will help you identify which debug window is performing the problematic memory reads.
Cannot set a hardware breakpoint
Most probably all available hardware breakpoints are used up. Either switch to software breakpoints or remove one or more existing hardware breakpoints.
There is no breakpoints left for debug commands
For high level debug commands (source step, run until...) hardware execution breakpoints are used. One hardware breakpoint is optionally reserved for these functions. Check the Debug / Debug Options / Debugging / Reserve one breakpoint for high level debugging option if it is not checked by default already.
Initial debug connection fails
When the debug tool cannot connect to the target or cannot gain control over the application, check the following:
>> Wrong CPU selected
Check the Hardware / Emulation Options / CPU settings. Correct family, POD/iCARD/iTAG, CPU and CPU variant setting must be selected.
>> Wrong adapter / iCard used
Check if you are using a correct debug adapter or iCard for your target.
>> Emulator connected to a wrong target connector
Check if the debug tool is connected to the correct target debug connector. Multiple target connectors can have the same physical appearance and size, but have different functionality.
>> Target is powered
Check if the target is turned on and if power supply is really applied to the microcontroller. Use volt-meter for confirmation (particularly on targets without visual indication of power supply presence).
>> Target is supplied with an incorrect voltage
Target must be supplied with the voltage in the range that is defined for it. Check the target reference manual for power supply specification.
>> Cable connecting the debug tool and the target is damaged
Inspect the cable for any physical damage. If possible, check the connections with ohm-meter. If it is damaged, contact iSYSTEM technical support for a replacement.
If communication between winIDEA and the emulator fails, an error is generated. This is the list of most common errors:
Orange LED blinking on the emulator
If you are experiencing issues with the emulator and the orange LED is blinking please contact iSYSTEM technical support and describe how the LED is blinking. The way LED is blinking will help them identify the problem with your emulator. Note that it is normal for the orange LED to turn on when the emulator is waiting for communication with the PC and turn off once the communication is established.