You are here

Debug directly with gdb instead of PSoC Creator | Cypress Semiconductor

Debug directly with gdb instead of PSoC Creator

Summary: 6 Replies, Latest post by simon.marchi_1659531 on 13 May 2016 01:27 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
andyturk's picture
10 posts

Creator is crashing every time I try to debug my project. Is there any way to use gdb directly?

It looks like Creator uses gdb behind the scenes (i.e., there's a gdb process while a debug session is active), so it should be possible.

The only thing I really need Creator for is setting up the components. Editing, compiling, linking, etc. can all be done without the IDE using the included toolchain.

user_78878863's picture
2553 posts

You can use tools like e.g. ProcessExplorer to get the complete commandline of the called gdb instance. That should allow you to use it directly.

user_151909305's picture
36 posts

 Interesting! If you manage to make this work, please post your results!

andyturk's picture
10 posts

 arm-none-eabi-gdb.exe is the actual GDB process. It's command line consists of the .elf file for debugging and a bunch of include directories for source. The "interpreter=mi" bit tells GDB to format it's output so that it's easy to parse by a program, rather than being parsed by a human being sitting at a keyboard. Here's what mine looks like:

"C:\Program Files (x86)\Cypress\PSoC Creator\2.2\PSoC Creator\import\gnu_cs\arm\4.4.1\bin\arm-none-eabi-gdb.exe" -interpreter=mi Z:\code\PSoC\sync\sync.cydsn\CortexM3\ARM_GCC_441\Debug\sync.elf -d Z:\code\PSoC\sync\sync.cydsn\Generated_Source\PSoC5 -d Z:\code\PSoC\sync\sync.cydsn -d Z:\code\PSoC\sync\sync.cydsn\TopDesign -d Z:\code\PSoC\sync\sync.cydsn\Generated_Source

GDB doesn't know anything about PSoC or any mcu for that matter. It relies on another process that talks to the board (aka the "remote target") via USB or whatever. In the Cypress world, I believe that process is "psoc5debugger.exe", which shows up as a subprocess of GDB. That probably means that PSoC creator feeds a command script to GDB which among other things, executes psoc5debugger.exe. The command line is something like this:

"C:/Program Files (x86)/Cypress/PSoC Creator/2.2/PSoC Creator/bin/cypsoc5debugger.exe" "-t" "PPIO:DVKProg5/00000F23350C:1" "-pin" "Cyd2StubPipe712" "-pout" "Stub2CydPipe712"

I'd guess that the PPIO:... thing refers to the USB interface of the (-t for "target"?) device and that -pin and -pout are I/O streams. Unfortunately, I don't know how GDB is actually hooking up to the psoc5debugger I/O streams. I've used openocd and Segger's J-Link for other projects and they simply present a TCP/IP server socket that GDB hooks up to via a "target remote localhost:<port>" command.

A little information from Cypress about how psoc5debugger works would go a long way. For my project, being able to debug independently of PSoC Creator is a hard requirement. Most of my codebase is written in C++. PSoC Creator doesn't know what to do with C++, and I'd guess that it's pretty far down on Cypress' to-do list. Even though I really like what PSoC5 has to offer at the hardware level, Cypress' IDE simply won't handle my code.

This is a real disappointment becuase the underlying GNU toolchain handles C++ just fine.

user_78878863's picture
2553 posts

So if the psoc5debugger is a sub-process of GDB, it shjould be started by GDB. In that case, you don't need to care about how to start it, and how it communicates with GDB. You just start GDB as Creator does.

But the command line looks as if the two processes use named pipes as communication mechanism:
"-pin" "Cyd2StubPipe712" "-pout" "Stub2CydPipe712"

I don't know whether the psoc5debugger process can be run like a GDBServer (as you did with other tool chains).

rgrr's picture
6 posts


any findings on this issue?

I'm currently trying to use gdb in conjunction with psoc4 from the command line.

The actual command lines when started from PSoC Creator are as follows:

PSoC Creator creates

"C:\Program Files (x86)\Cypress\PSoC Creator\3.1\PSoC Creator\BIN\cyspawnapp.exe" -n "GDB_4876_21" -- D:\b\gcc\gcc-arm-none-eabi-4_8-2014q3-20140805-win32\bin\arm-none-eabi-gdb.exe  -interpreter=mi "D:\u\PSoC Creator\SWA70\Spiel.cydsn\CortexM0\ARM_GCC_Generic\Release\Spiel.elf"

cyspawnapp then starts
"D:\b\gcc\gcc-arm-none-eabi-4_8-2014q3-20140805-win32\bin\arm-none-eabi-gdb.exe" -interpreter=mi "D:\u\PSoC Creator\SWA70\Spiel.cydsn\CortexM0\ARM_GCC_Generic\Release\Spiel.elf"
 arm-none-eabi-gdb then starts
"C:/Program Files (x86)/Cypress/PSoC Creator/3.1/PSoC Creator/bin/cypsoc4debugger.exe" "-t" "PPIO:KitProg/0A08043602213400:1" "-pin" "Cyd2StubPipe4876" "-pout" "Stub2CydPipe4876"

4876 is the PID of PSoC Creator.  Notice that not the cypress GCC toolchain is used, instead a generic one.

Starting just the arm-none-eabi-gdb.exe with all its arguments from the command line does not start cypsoc4debugger.

So I'm wondering how arm-none-eabi-gdb starts pypsoc4debugger if running under the Creator!? gdb logging does not reveal anything useful.

Any ideas?


simon.marchi_1659531's picture
1 post

I re-built gdb from source, using pretty much the configuration flags shown with the "show configuration" command.  I added a bit of code to log the MI commands received by GDB to a file, so that we can see how PSoC Creator interacts with GDB.  Here's an example of MI commands for a simple debug session:

I then tried to run gdb directly...

    > arm-none-eabi-gdb.exe "c:\Users\simark-vm\Documents\PSoC Creator\Workspace01\Marc-AndreDesign02.cydsn\CortexM3\ARM_GCC_493\Debug\Marc-AndreDesign02.elf"

And ran the CLI equivalent of the -target-select command used by PSoC Creator:

    (gdb) target remote | C:/Program\ Files\ (x86)/Cypress/PSoC\ Creator/3.3/PSoC\ Creator/bin/cypsocdebugger.exe -t PPIO:KitProg/091207DE002E4400:1

The response was "Unknown remote qXfer reply: OK".  I then tried the command a second time, and this time it worked!  I am now able to step in the code using command line GDB.  I tried modifying memory, adding a watchpoint, it worked well.

I then tried to disconnect and reconnect my dev board, to see if I could do it again.  This time I was given:

The target device 'PPIO:KitProg/091207DE002E4400:1' could not be found.
Remote communication error.  Target disconnected.: No error.

The difference between the two runs is that the first time, I had started a debug session previously using PSoC Creator, so the debug session was still up.  Starting a new instance of cypsocdebugger.exe probably only picked up the already setup session.  I don't know why I got the "Unknown remote qXfer reply: OK" response though.  More work would be needed to be able to start a debug session from scratch, without invloving PSoC Creator at all.

Log in to post new comments.