For local builds, I’m currently using the GCC toolset documented by Spark on their firmware page on GitHub with my standard editor Sublime Text 3, all running on 64-bit Windows 8.1. Debugging is done via 115200 baud serial writes to the second serial port - the hardware USART on the TX and RX pins - feeding back to TeraTerm.
While this works OK, I’d prefer something better, especially for debugging. I’m willing to spend up to $200 for a ARM toolset that offers significant improvements.
CodeSourcery generates better code, smaller memory usage. Prices vary based on addition. 30 day free trial for Linux or Win32 - to me it runs better on Linux
with a Segger JLink it it unstoppable, but I am sure you can use eclipse and GDB server for th JLink
@BDub I was never able to get Serial over USB to work consistently. With Serial1, I can reset and update the Core without restarting TeraTerm, yet still see the serial data the next time it starts streaming. It just works all the time.
@david_s5 CodeSourcery looks great and has a reasonable cost for non-commercial use. The Segger J-Link looks good as well but the price for just the Base unit - ouch!
You can try and google around for the EDU model or other compatible ones, or order an IAR kit that comes with one. The cool feature is unlimited Flash Breakpoints (CodeSourcery will hopefully support it in the near feature) but you can use the Segger GDB server and use them now.
@bkize Are you taking about Serial USB going way on reboots? That is normal, as the ACM/CDC driver closes the port. Putty gives an error and you have to restart it.
@david_s5 Yes, that’s the issue with using Serial USB. And why I use Serial1 instead with a serial-to-USB converter - that setup works much better IMO.
When we need step-through debugging internally at Spark (which isn’t that often, maybe once a month) we use the JTAG shield with the STLINKv2 and arm-none-eabi-gdb on the command line with st-util at an extended target. So basically:
plug the STLINK USB into the computer
plug the STLINK ribbon cable into the JTAG shield
power the Core through its USB jack
plug the Core into the JTAG shield
put the Core in DFU mode where JTAG is enabled
in one terminal window run st-util -p 9025 (port number doesn’t matter, just pick one that’s available)
all the following commands in another terminal window in the core-firmware build directory
export USE_SWD_JTAG=y (see build/makefile and inc/main.h in core-firmware)
make clean all
arm-none-eabi-gdb core-firmware.elf
you’ll now be at the gdb prompt
target extended :9025 (or change the number to the port where you’re running st-util)
load (which writes your firmware through the STLINK to the Core)
break loop (sets a breakpoint at loop() in application.cpp), should say: “Breakpoint 1 at 0x80xxxxx: file …/application.cpp, line XX.”
c (or continue, will execute code and break on first breakpoint)
Output looks like this:
Breakpoint 1, loop () at …/application.cpp:XX (XX is the line number)
XX // whatever your first line of code is in loop()
n (or next, code will step OVER next command. Useful if you don’t want to execute every line of a function like delay(250); )
s (or step, code will step INTO next command. Useful if you need to execute every instruction sequentially)
delete (can delete all breakpoints)
if you continue with no breakpoints set, press CTRL+C twice to HALT.
quit (exits the debugger)
###Don’t run these immediately after LOAD, but you can run them later on.
kill (and answer yes when prompted with “really?”)
set breakpoints as needed, e.g., break setup to stop when setup() gets called
