Invalid Memory References while using the ICE to Debug | Cypress Semiconductor
Support & Community
Invalid Memory References while using the ICE to Debug
What is an Invalid Memory Reference (IMR)?
The IMR error occurs when the internal states of the in-circuit emulator (ICE) and pod diverge. There are multiple possible causes for this divergence. An IMR is reported when the PSoC Designer debugger detects a mismatch between the emulated M8C registers and SRAM in the ICE-base station, and the registers and SRAM in the PSoC® device on the emulation pod. You can think of an IMR as the result of the ICE losing track of what the pod is doing.
The IMR errors must be fixed before you continue debugging. Many reasons why IMR errors occur are fixed in the most recent versions of PSoC Designer and current generations of the PSoC microprocessor. You can work around IMRs or prevent the remaining IMR issues using proper methodology in project code. An IMR does not necessarily imply that your application contains faults when programmed into a part outside of the debugging environment.
Use version 4.2 or later of PSoC Designer. Earlier versions contained bugs that led to IMR errors. Also, make sure that you do not use obsolete PSoC devices.
Using phase locked loop (PLL) while debugging prevents the debugger from operating correctly. To avoid this error, debug with the PLL off. Disable the PLL in the Global Resources window of PSoC Designer. Make sure to disconnect any external crystal hardware you may have attached to the PSoC device.
Use care when debugging code that sets the sleep bit.
- Do not attempt to use the debugger to step over a register access instruction that sets the sleep bit. This causes an IMR error.
- Do not attempt to set a breakpoint immediately after a register access instruction that sets the sleep bit. This causes an invalid memory reference.
System Supervisor Call Issues
Follow these guidelines when executing the system supervisor call (SSC) instruction.
- Do not attempt to execute the SSCinstruction without using the SSC_Action( OpCode )macro. The macro is provided in the m8ssc.inc file that can be included in your PSoC projects. If you do not use this macro, it is likely to generate an IMR error.
- If you set a breakpoint immediately after either the SSC_Action( OpCode )macro or an SSCinstruction, the breakpoint is skipped and the program does not halt at that instruction.
- It is not necessary to use SSCinstructions or the SSC_Action( OpCode )macro to access the SROM. Many functions are provided in the API libraries that implement SROM access functionality.
See the Assembler Includes section for instructions on how to include m8ssc.inc.
Flash Read Issues
If you are using a CY8C27x43 device and your code erases part of the flash and does not rewrite it with definite data, then you get an IMR error when you try to read that part of the flash with the ROMXinstruction. PSoC Designer initializes all of the flash memory with data, even if the project code does not require the entire program memory space. However, in all CY8C27x43 devices, flash memory does not reinitialize to a definite value after it is erased.
Other PSoC 1 device families do not have this problem because they use a flash memory with values that are defined as 0 after it is erased.
If the ReadBlockSROM function is used to read flash data into RAM, then no error occurs, even if the flash is erased and still contains indefinite data. It only occurs with a read from flash using the ROMXinstruction.
To prevent these errors when debugging a CY8C27x43 device, either use the functions described in the flashblock.inc file or the E2PROM User Module. Using either of these mechanisms makes it much easier to erase, read, and write data to the flash without having to worry about IMR errors.
Some IMRs are caused by power fluctuations in the debugging pod or target system. If a project has two conflicting drivers for the same global line (for example, digital block A drives a global line low and digital block B drives it high), the resulting power drain can collapse the pod power rails. This causes the pod to crash and an IMR to result. The same thing can happen with a pod in a system with noisy power. For example, a system with a marginal power supply and an electric motor can have IMRs when the motor turns on.
In rare cases, some ICE base stations can cause IMRs when running at the fastest CPU frequencies. Swapping the ICE base stations can rule out any issues with the ICE. It is also possible that any problems with the debugging pod hardware can also cause the IMR error to occur. It is recommended to swap the pod hardware and check if the error still occurs, to rule out any hardware issues. If it is determined that the debugging tool hardware is causing the IMR errors, contact Cypress Technical Support.
Assembly language include files, such as m8ssc.inc and flashblock.inc, that are located in the directory where you installed PSoC Designer. For example, if you are using a CY8C27x43 PSoC device, then the include files for that particular family are located in the following directory path:
If you are using a different device family, then change the last folder of the directory path accordingly. To include these files using assembly language, type INCLUDE "flashblock.inc" at the top of your main.asm file.
Many of the causes for getting invalid memory reference errors are fixed in the most recent version of PSoC Designer. However, there are still some ways to cause the ICE to lose track of what has happened in the pod. There is always a reason why these errors occur and there is always a way to prevent these errors. The best approach is to prevent them before they occur.