PSoC 6 MCU Multi-Core Debugging with Third-Party IDEs – KBA222959

Version 3

    Version: **


    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


    Eclipse CDT Multi-Core Debugging

    Current status:

    Multi-core debug support is being added incrementally to Eclipse CDT, but with some limitations. For more details, see

    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 (Neon)

    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.

    Figure 1


    Set entries on the Startup tab as Figure 2 shows:

    Figure 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.

    Figure 3


    On the Setup tab, deselect the following as Figure 4 shows:

    • Initial Reset and Halt
    • Enable SWO
    • Load executable
    • Pre-run/Restart reset


    Figure 4


    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.


    Figure 5

    Running Eclipse

    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.


    Figure 6


    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().