winIDEA HelpMulti-core Debugging
This chapter explains NXP/ST Power Architecture multi-core debugging. debug functionalities. For general debug information refer to Multi-core Debugging.
Debugging Multi-Core Application
When a microcontroller features two or more cores, each core is debugged in an individual winIDEA instance. In order to debug the second (non-primary) core (for example 2nd e200z0 core of the MPC551x), first primary winIDEA instance and workspace is opened, which allows compiling the complete project, downloading the code in the MCU program flash and debugging the primary (main) core.
In order to debug the 2nd core (e200z0H in the below screenshot), new winIDEA instance is opened from the Debug / Core menu.
2nd core is debugged more or less in the same way as a primary core. 2nd core winIDEA instance provides all standard debug windows such as Disassembly Window, Memory Window, Watch Window, Locals Window, Source window, Trace window, etc.
The application code for 2nd (and any further) core is loaded by the primary winIDEA instance/workspace, which downloads the application code in the MCU internal program flash. Program flash is shared amongst all cores available. 2nd (and any further) core winIDEA instance requires to download only symbols for the specific core being debugged. Don’t forget to specify the necessary download file including debug symbols in each non-primary core winIDEA instance.
Typically, when the microcontroller is released from the reset state, the main core first executes code from the Boot Assistant Module (BAM), which initializes certain modules (e.g. MMU), then reads reset configuration and starts the user code.
Typically, all other non-primary cores are started by the primary core application code. On certain MCUs (NXP MPC57xx or ST SPC57), other cores can also be started directly by the Boot Assistant Module already, which means they can start running at the same time (out of reset) when main core starts executing the code.
Execution Breakpoints
Typically, the debugger (primary winIDEA instance) downloads the application code in the program flash and stops at program start point. At this point in time, all other cores are still in the reset state. The state could be different if the Boot Assistant Module (where applicable) would start the other non-primary cores directly.
Now, if the user sets execution breakpoint(s) on any non-primary core, these are not applied to the specific core yet since the core is still in reset state and the debugger has no control over its operation yet. For the same reason on-chip breakpoint logic is not operational yet either. In this stage, the debugger periodically (few times per second) checks the debug status (reset, run, stop, etc.) of each core. As soon as the debugger detects that the non-primary core is being released from the reset state (which happens when main application is being run), it configures the on-chip debug logic and applies the execution breakpoints. This results in a certain delay between the moments when the core exits reset and when the execution breakpoints start acting. Consequentially, certain code on this core is being executed already before the execution breakpoints start acting. Clearly, any execution breakpoint, set in this part of code being executed from reset on only, will not hit.
If such behavior is not desired, the debugger provides, for each non-primary core, an option Stop when released from reset in the Core-specific pages in the Hardware / CPU Options dialog. When this option is checked, the core will stop immediately after exiting the reset. Check this option, when main focus is debugging the code being executed immediately after reset and not a real-time behavior of the complete target application. For real-time application behavior, this option should not be checked.
Software execution breakpoints are not available on non-primary cores since setting and clearing a software breakpoint means reprogramming (erase-program) the program flash. Any non-primary core could in the meantime, while software execution breakpoint is being applied, try to execute the code from the same flash sector, which would result in the application malfunction.
Debugger still provides software execution breakpoints for the primary (main) core. They can be used when debugging a single core application (either on a single or a multi-core microcontroller). However, as soon as the application runs on multiple cores, software execution breakpoints should not be used to prevent problems mentioned in the previous paragraph.
eTPU Debug
The Enhanced Timing Processor Unit (eTPU) has its own Nexus class 3 interface, the Nexus Dual eTPU Development Interface (NDEDI). The Nexus Dual eTPU Development Interface provides real-time development capabilities for the eTPU system including two engines and the coherent dual parameter controller (CDC) in compliance with the IEEE-ISTO 5001-2002 standard. The main development features supported are hardware execution breakpoints, register and memory access, instruction and source step, run/stop control, branch (program) trace, data trace and ownership trace. Combined, these features make the interface for each engine compliant with Class 3 of the IEEE-ISTO 5001-2002 standard.
In order to debug the MPC5500 application, first a main winIDEA workspace window must be open, which allows compiling the complete project, downloading the code in the CPU internal flash and debugging the e200 core, eDMA and FlexRay. In order to debug the eTPU1 or the eTPU2, a new winIDEA session is open for each eTPU being debugged from the Debug / Core menu. Refer to chapter Multi-core Debugging for more information.
In general, eTPU1 and eTPU2 modules are debugged in the same way as an e200 core. Each eTPU module has its own winIDEA instance with standard debug windows as disassembly window, memory window, watch window, source window, trace window, etc. However, note that the code for eTPUs is loaded by the main workspace, which loads the code into the internal flash. eTPU winIDEA session must therefore download only symbols, which are required for high-level eTPU debugging. Don’t forget to specify the necessary download files for each eTPU winIDEA session.
SPT Debug
In order to start debugging the Signal Processing Toolbox (SPT) open the winIDEA workspace of the main core and establish the debug session.
 Open SPT winIDEA instance by selecting Debug / Core / SPT. |
 SPT is different than a typical core handled by winIDEA, therefore the debug experience differs as well. SPT may be in any of the following states:
Status display in winIDEA instance for this core will reflect these states instead of typical statuses (stop, run, halted, reset) in order to provide more clarity to the user. One of the major differences is the STOP state. On other cores this status means that the execution of the user's code is stopped and the core is ready for debug. On SPT, however, this means that a STOP command was used and debugging is not possible. Instead, there is a DEBUG state, which means that the CPU has stopped executing user's code and is ready for debug. SPT has 4 breakpoints, but they work as post-execution breakpoints. Note that Run command typically puts the SPT in RUN state, but if there are any breakpoints set, then the SPT will step until the next breakpoint (enter RUN state and then immediately enter DEBUG state). This is done automatically by SPT. |
SPT Instruction Jamming
Instructions may be directly filled to the command sequencer. This can be done through winIDEA SDK. Following is a python example for SPT instruction jamming:
import isystem.connect as ic
cmgr = ic.ConnectionMgr()
cmgr.connectMRU('')
ideCtrl = ic.CIDEController(cmgr)
print(ideCtrl.serviceCall('/IOPEN/HW.Debug.InstructionStuff', 'InstrHex: 04000000000000000000123456789abc'))
#set.immed 0x123456789ABC, WR_0
ideCtrl.refreshUI()
