Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
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
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().