PSoC 6 MCU Multi-Core Debugging with Third-Party IDEs – KBA222959
Translation - Japanese: サードパーティIDEによるPSoC 6 MCUマルチコアデバッグ - KBA222959 - Community Translated (JA)
How do I debug a PSoC® 6 MCU Multi-Core Project in third-party IDEs?
For IAR IDE, see the overview at https://www.iar.com/support/resources/articles/multicore-debugging/
Eclipse CDT Multi-Core Debugging
Multi-core debug support is being 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 it can only be used to debug systems that share code across all inferiors.
- GDB 7.1 extends that 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).
- This work was developed and tested on Linux; may not work on Windows
- Requires “non-stop mode” debugger support, which allows some threads to be stepped while others are running 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
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.
Eclipse has a relatively new feature in which you can create a “launch group” – this allows you to bundle several other existing launches and start them 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 two projects, one for the CM4 core and the other for the CM0+ core, as follows:
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.
Set entries on the Debugger tab as Figure 1 shows.
Set entries on the Startup tab as Figure 2 shows:
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
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.
When started, the launch group starts three separate debug launches, as shown in Figure 6. The first is the launch group itself – terminating this launch will also terminate the other two.
The other two are for 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 on.
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().