Copying this from LPC1768 discussion for more visibility.

Drag-n-drop programming from the cloud compiler is very convenient - for simple projects and getting new users started. And it is fast - typically taking only some seconds to download and then reset the module. But here, printf is your friend, and often your only friend, (supplemented somewhat by the LEDs).

CMSIS-DAP , in firmware 141212, appears to offer a lot more capability for programming, break-points, single-step, register access and more.

From my side, using Win7 and now Win10, I have struggled mightily to find a scenario that works - and I haven't found a combination that is "usable". One collection of tools took about 3 minutes to successfully download and run "blinky".

Focusing on the LPC1768 module which has the LPC11U24 as the debugging host:

• What PC toolset are you using [compiler, debugger s/w, driver combinations, etc]?
• What is the performance you see [how long to program, how responsive is it when stepping]?
• Is there a setup/configuration/web guide that you followed?

Other modules If you are using a different mbed module, and perhaps with an external debug tool, can you similarly share your experience?

• What module?
• What debugging tool?

Hi David

I've tried debugging the LPC1768 with CMSIS-DAP and have found it to be completely unusable. It took me a couple of days to get it even in a semi-working state.

Takes ages to flash the mbed-os-example-blinky program (approx. 5 mins) and then simple commands (such as writing to a digital output) take anywhere upwards of about 15-20s to execute.

1. Build Environment: Windows 10 x64
2. mbed interface (LPC11U24) F/W : 141212
3. IDE: Eclipse CDT (Oxygen Release (4.7.0)) with GNU ARM Eclipse Plugin tools and GNU ARM Eclipse Windows Build Tools
4. mbed-cli: Used the" gnuarmeclipse" export function to set up the project as a managed CDT project in Eclipse
5. Build Toolchain: GNU Tools ARM Embedded (6 2017-q2-update)
6. GDB Server: OpenOCD (latest from GNU ARM Eclipse plugins)
7. GDB Client: arm-none-eabi-gdb.exe (included with GNU ARM toolchain)

I followed the guide on the http://gnuarmeclipse.github.io/debug/openocd/ site.

However, I found I had to add "-c "init; reset halt"" to the openocd command in order for OpenOCD to halt the target properly before flashing. This was not covered in the guide.

Hi - I'm trying to debug STM32F746G-Disco using VS code + arm-none-eabi-gdb.exe+ pyocd-gdbserver.exe . All latest verisons and firmware updated. Although the board works fine on the standard MBEd online compiler, I'm stuck in VS code at : ERROR Unable to start debugging. No process is associated with this object. I've tried everything I can think of and searched high and low! Can some one explain what may be wrong? Thanks.

PS - I'm using windows 10

I use Eclipse (or Qt Creator) as IDE and pyOCD as GDB server to debug mbed LPC1768 offline on a Windows 7 (32-bit) system. It's quite fast for MBED OS 2 but a bit slower for MBED OS 5 (especially the execution of Thread::wait() function). Nevertheless, it works and I think it's usable.

• To install Eclipse I followed the Eclipse tutorial.
• Then I downloaded and installed Python 2.7.14 from this site.
• Instruction for installation of pyOCD are available here.
  NOTE: Before issuing the pip install --pre -U pyocd command from a Windows Command prompt window, I recommend to add the path to the 'pip.exe' (e.g.: C:\Python27\Scripts) to the system PATH variable.
• Once the project has been exported (Export toolchain: Eclipse_gcc_arm), unzip it and import to Eclipse as explained in the tutorial.
• To ensure that debug information will be generated, open the Makefile and append '-O0' '-g' at the end of line CPP = 'arm-none-eabi-g++' '-std=gnu++98' ... '-mthumb', so it becomes
  CPP = 'arm-none-eabi-g++' '-std=gnu++98' ... '-mthumb' '-O0' '-g'
  
• After that, clean and rebuild the project in Eclipse.
• Once done, follow the Eclipse tutorial for the pyOCD part.
  NOTE: Make sure you provide a full path to the pyOCD executable (e.g.: C:\Python27\Scripts\pyocd-gdbserver.exe) and the Debugger client (e.g.: D:\mcu\arm\gcc-arm\bin\arm-none-eabi-gdb.exe).
• It takes about ten seconds to flash the board and a fraction of second to switch a DigitalOut pin or to execute a printf() function during debugging. What takes more time than suppose to is the execution of Thread::wait() function.