Install Netbeans
Okay, now it is finally time for NetBeans.
Download it here: https://netbeans.org/downloads/
Choose the C/C++ version. You might have to install the Java SDK.
Install Cygwin
NetBeans needs Cygwin to compile your code. Install the 64 bit version if you are on a 64 bit machine.
Download it here: https://cygwin.com/install.html
Just install the default packages (you don’t need to select them, just click next twice).
Install NetBeans Plugins
Start NetBeans, go to Toos–>Plugins–>Available Plugins
Install the Gdbserver plugin, the C/C++ plugin should be already installed.
Set up your ARM toolchain in NetBeans
Tools–>Options–>Build Tools–>C/C++
Add a new tool collection and set up the following tools:
And set up the build tools, in particular be sure to set the debugger to arm-none-eabi-gdb from your arm gcc install:
Create a new project from existing sources
File --> new project --> from existing sources
Select your firmware directory, leave configuration at automatic, choose your ARM tool collection
MinGW make didn’t work with an absolute path.
This bug is worked around by just setting the make command to make.exe (which works because it is in the PATH)
Now the build works 
Programming the core via the ST-LINK V2
I have not find a way to program the core and attach the debugger in one go, but I have found a good workaround:
We will set up the run button to program the core and we will use the ‘attach debugger’ button to start debugging afterwards.
But first of all, we have to make sure that the new firmware we are going to flash to to the core also has debugging enabled. Add USE_SWD_JTAG=y to the make command.
If you forget this, you will have to reflash with dfu:
Make a new file with a few gdb commands to upload code to the core:
# connect remote gdbserver on port 9025 (started with st-util -p 9025)
target remote localhost:9025
# reset core and hold in reset
monitor reset halt
# program core with supplied .elf file
load
# jump to spark core reset handler
jump Reset_Handler
# remove all breakpoints
delete
# continue execution (TODO: continue in background so we can disconnect while running continues)
continue
# disconnect from remote. This pauses execution. Detach is not supported.
disconnect
quit
So add that to a text file and save the file as gdbprogram.txt somewhere outside of your repository.
This will program the core via the ST-Link V2 and starts running the program. I have not found a way to detach from the debugger after programming without pausing execution. So you’ll have to exit with CTRL-C in the output window in Netbeans.
Now right click your project and open properties.
On the ‘run’ tab, set up your run command as (adapt for your paths) and check ‘build first’.
Run command:
arm-none-eabi-gdb main.elf -x c:\repos\gdbprogram.txt
Run directory (path to main.elf):
.\build\target\main\prod-0\
Screenshot:
Now hit the run button. It should compile the code and send it to the spark via the GDB server via st-util:
As you see, st-util exited after programming. That’s where this .bat file comes in handy:
:loop
st-util.exe -p 9025
goto loop
It will keep restarting st-link until stopped with CTRL-C.
Finally: attaching the debugger
For the gdbserver plugin to work, we will have to set the build result under the make settings to point to our .elf file.
We will test debugging with the Tinker app. Change your make command and build result to compile with the tinker app:
And your run settings:
Please someone find a way to do this automatically!
Now compile and flash again with the run button, and then attach the debugger:
Voila! Programming and debugging in Netbeans with the click of a single button!
BTW, blink is a bad test program for this. The little blue LED next to the USB connector is connected to one of the JTAG pins and will not blink.
Make sure you have set a break point in your program before running, because the pause button does not work. Once you have hit a break point, you can step through the program or run from break point to break point.
# set limits of the hardware
set remote hardware-watchpoint-limit 6
set remote hardware-breakpoint-limit 4
# jump to spark core reset handler
jump Reset_Handler
continue
Save it as gdbattach.txt and load it in the debug settings:
This will reset your program when you attach the debugger.
And as you can see below, the debugger stopped at the break point 
Issues I have encountered
Once your core has breakpoints set, it will not run freely, even when no debugger is attached.
Make sure your spark core is set up on your WiFi first. I brought a spark home from work and it hung on flashing green. It was a bitch to get it back on the network with the custom debugging builds running and the debugger attached.