winIDEA HelpDebugging
Open Hardware / CPU Options / Debugging.
Synchronize selected cores (stop/run) when possible
Checked option configures available on-chip debug logic for cores to stop and run at the same time when debugging. If you want a specific core to be included in the synchronization, the Cores / <core> / Synchronize this core option must be checked as well.
|
Note that all synchronization combinations might not be possible. The possibilities are determined by the target architecture, synchronization resources, SoC restrictions, etc. Refer to the reference manuals and descriptions of used architecture and SoC for more information. |
When the option is checked, then a software breakpoint is not set / cleared immediately, but is just remembered. Only when the CPU is set to running are the breakpoints committed. This way several breakpoints can be changed but only one re-FLASH operation takes place. This is especially noticeable in testIDEA operation with many stubs and also during a regular debugging session when several breakpoints are set / cleared within the same flash erase block.
Set this to core clock. It might be used internal FLASH programming timing, depending on the CPU that is being used. When it is used for both set to core clock valid when trace is active then use initialization sequence to set the CPU clock the same frequency for programming.
|
Note that this setting is critical to FLASH operations on many CPUs. |
If flash programming fails, check if this setting is correct. This setting must be valid at the moment when flash programming is performed. When the application is first downloaded the CPU runs on the default clock (out of reset). This means that the clock setting must be correct at the time of download. If you wish to use software breakpoints / write to flash once the CPU clock is changed (e.g. PLLs are used), then it is necessary to set this setting to the clock that is valid at this time and create a winIDEA initialization script that will set the CPU clock to the same frequency prior to application download. This ensures that the CPU clock setting is valid both at the time of the application download and later on as well. Refer to Initialization Sequence for more information.
Example (50MHz is entered as CPU clock):
a.CPU runs on 12MHz out of reset (download will not work)
b.Initialization script sets the CPU clock to 50MHz
c.Download is performed
d.CPU is reset (clock is reset back to 12MHz) – if Reset CPU after DL/reset option is enabled
e.Flash operations / trace unoperable until the clock is set to 50MHz by the application
|
This might not be necessary on all Cortex devices, but most Cortex-M NXP LPC devices need CPU clock to correctly program FLASH memory. |
Simulate instr. step
Never is selected by default. When run or source step debug command is executed from a BP location the debugger first clears BP, executes single step, sets back the original BP and then resumes the application. All this is done in background hidden from the user. Since setting and clearing software flash breakpoint can be very time consuming the new approach was introduced. It simulates the first instruction at breakpoint address without clearing and setting the software flash breakpoint. Thereby the user can select FLASH SW BP in order to speed up the debugging. Not all instructions can be simulated successfully. If the option yields erroneous behavior, set back to the default setting.
Ignore Access errors
When checked, the debugger identifies memory access errors for individual memory location(s). When the option is unchecked, the debugger would declare access error for remaining memory locations once one access error is detected within a memory read block, which is used in the Disassembly Window or Memory Window.
Cache downloaded code only - do not load to target (deprecated)
When checked, the download files will not propagate to the target using standard debug download but the Target download files will.
In cases where the application is previously programmed in the target or it's programmed through the flash programming dialog the user may uncheck Load code in the Properties dialog when specifying the debug download file(s). By doing so the debugger loads only the necessary debug information for high level debugging while it doesn't load any code. However, debug functionalities like trace will not work then since an exact code image of the executed code is required as a prerequisite for the correct trace program flow reconstruction. This applies also for the call stack on some CPU platforms. In such applications Load code option should remain checked and Cache downloaded code only (do not load to target) option checked instead. This will yield in debug information and code image loaded to the debugger but no memory writes will propagate to the target, which otherwise normally load the code to the target.
The option is deprecated but kept for back compatibility. When target memory(s) have the application already programmed user should perform Load Symbols Only. The operation is equal to Download operation only without physically programming the target memory(s).
Image checker
Not implemented on ARM Cortex devices.
Optional Device Checks
Select optional image checks available before flash programming.
