Version: **
Translation - Japanese: サードパーティIDEによるPSoC 6 MCUマルチコアデバッグ - KBA222959 - Community Translated (JA)
Question: How do I debug a PSoC® 6 MCU Multi-Core Project in third-party IDEs?
Note: The information in this document applies to designs exported from PSoC™ Creator. For information about ModusToobox™ applications, refer to the ModusToolbox™ Tools Package User Guide.
- For IAR IDE, see the overview at https://www.iar.com/support/resources/articles/multicore-debugging/
1.1 Eclipse CDT Multi-Core Debugging
Note: This article was initially written in 2018 for the Neon version of Eclipse. As of this update, the current Eclipse version is 4.25.
Multi-core debug support was added incrementally to Eclipse CDT, but with some limitations. For more details, see https://sourceware.org/gdb/wiki/MultiProcess.
It depends on underlying support from GDB, as follows:
- GDB 7.0 has basic support for multi-process inferior control implemented in the remote target, but can only be used to debug systems that share code across all inferiors.
- GDB 7.1 improves by providing support for multi-process and multi-executable debugging for Linux systems (native and remote) as well. This means being able to load several programs under a single GDB session; "run" or "attach" to several processes under a single GDB session, each possibly running a different program; or following all the forks and execs of an inferior and its children tree.
- GDB 7.2 adds support for multi-executable control to the machine interface (MI).
Note: This work was developed and tested on Linux, as such, it may not work on Windows.
GDB requires "non-stop mode" debugger support, which allows some threads to be stepped while others run freely. To enter non-stop mode, use this sequence of commands before you run or attach to your program:
# If using the CLI, pagination breaks non-stop.
set pagination off
# Finally, turn it on
set non-stop on
Note: PSoC Creator™ versions 4.1 and 4.2 use a GNU Arm® 5.4.1 package, which includes arm-none-eabi-gdb 7.1.0.
1.2 Eclipse (Neon)
Eclipse has a "launch group" feature. This allows you to bundle several other existing launches and start the launches all at the same time, at a delay from one another, or start one after its predecessor completes.
Create a launch group for a PSoC™ 6 MCU design comprising of two projects, one for the CM4 core and the other for the CM0+ core, as follows:
1.2.1 Create a CM4 Debug Launch
The CM4 launch configuration is based on the CM4 project, which is for a combined CM4/CM0+ image. The "launch group" mechanism shown below is scalable beyond two cores.
Refer to the following image to set entries on the Debugger tab:
Refer to the following image to set entries on the Startup tab:
1.2.2 Create a CM0p Debug Launch
This launch configuration is based on the CM0+ project, which contains only CM0+ code.
Make the following changes on the Debugger tab as Figure 3 shows:
- Check the Connect to running target check box.
- Set the Device name to CY8C6xx7_CM0p.
- Change the default GDB Port to 2431.
On the Setup tab, deselect the following as Figure 4 shows:
- Initial Reset and Halt
- Enable SWO
- Load executable
- Pre-run/Restart reset
Note: If you are debugging non-secure applications on the CM0+ core with JTAG, the Run/Restart commands box should also contain the following lines:
set $sp = *(uint32_t*)0x10000000
set $pc = *(uint32_t*)0x10000004
1.2.3 Create a Launch Group
As Figure 5 shows, create a Launch group, and add both the CM4 and CM0+ debug launches to it.
Create them with no associated “actions” (like a delay between the two launches). When you start this launch group, Eclipse launches both the CM4 and CM0+ configurations.
1.2.4 Running Eclipse
Once started, the launch group begins three separate debug launches, as shown in the image below. The first debug launch is the launch group itself, note that terminating this launch will also terminate the other two launches.
The two other launches correspond to the CM4 and CM0+ cores and operate independently, allowing you to switch your focus between the two cores, step them independently, examine values, and so forth.
Note: When you set a breakpoint on entry into main() for CM0+ (via the check box at the bottom of the debug launch configuration’s Startup tab), the core does not halt there. You must add a breakpoint later in the main() routine in order to halt inside main().