Each winIDEA core is controlled by a separate winIDEA instance. Primary winIDEA connects to the primary core (core that automatically starts after reset and is designated as first by its reference manual). Once debug session is established with the primary core, additional winIDEA instances may be opened through Debug / Core sub-menu:
Opening additional winIDEA instances for control of non-primary MCU cores
Note that debug session must be established before other cores become available. New instance of winIDEA will be started and will automatically open a workspace with the same path as the primary workspace with the addition of the core name (<primary workspace directory path>\<primary workspace filename>_<CPU name>.xjrf). In the example above this means E:\TriCore\TC\TC277TE\SampleiC5k_CPU1.xjrf. If the workspace doesn't exist, it will be automatically created.
These additional winIDEA instances do not require any detailed settings, as everything is configured from the primary winIDEA instance (e.g. Hardware / CPU Options / CPU1). The only exception are debugging and download file settings. Primary winIDEA instance will typically download code for all cores, but will only load symbols for the primary core. To prepare download file list for the primary winIDEA instance open Debug / Files for download:
Settings that control whether code and symbols are downloaded in this winIDEA instance
List download files for all MCU cores, but disable Load Symbols on all except the download file for the primary core. Additional winIDEA instances should list the download file that holds the symbols for that specific core only. Do not load the code - load only the symbols, as the code was already downloaded with download to the primary core:
Settings that control whether code and symbols are downloaded in CPU1 winIDEA instance
Debug session for non-primary cores is then established by clicking on Download / Load Symbols command. Note that depending on the MCU architecture, non-primary cores may not be started immediately after reset. winIDEA does not interfere with the application, therefore such non-primary cores need to be enabled by the application in the primary core (same, as they would be if the debugger would not be attached to winIDEA). If you wish to start the core immediately regardless, then an appropriate initialization script in the primary winIDEA instance may be used.
Depending on the MCU used synchronization between the cores may be configured either through winIDEA or through initialization scripts. For TriCore Aurix family initialization script must be used (refer to OCD TriCore chapter for more information), on others synchronization may be set through the primary winIDEA instance (Hardware / CPU Options / Synchronization):
Synchronization settings on an MPC56xx target