Check the Configuration¶
This chapter requires embedXcode+ and an Arduino M0 Pro board, an Intel Edison board, a LaunchPad board with a built-in hardware debugger, a chipKIT board with the external chipKIT PGM programmer-debugger, a mbed-enabled board, a Microsoft Azure IoT DevKit or a Cortex-M-based board with a connector for the Segger J-Link emulator. Debugging requires boards with a built-in hardware debugger.
Debugging has been tested successfully on the following boards:
Arduino M0 Pro board using the programmer USB connector,
Arduino Primo using the USB connector,
Arduino Due board using the Segger J-Link emulator,
Adafruit Feather M0 and Adafruit Feather nRF52 boards using the Segger J-Link emulator,
Intel Edison board with the Yocto environment connected with either WiFi or Ethernet over USB,
Most of the LaunchPad boards, including MSP430G2, MSP430F5529, LM4F120 Stellaris now TM4C123 Tiva C, CC3200 WiFi, MSP432,
chipKIT Uno32 with the external chipKIT PGM programmer-debugger,
Micrososft Azure IoT DevKit.
Other boards may support debugging but haven't been tested.
For more information on how to install the tools,
- Please refer to Install Drivers for Programmers and Debuggers .
Debugging involves two phases:
First, define the breakpoints with the associated conditions and actions within the standard Xcode interface.
Then, performe an debugging session in a Terminal window or with the Segger Ozone application while the sketch is running on the board.
Contrary to some debuggers, it is not possible to change breakpoints interactively during a debugging session, unless you use the command line interface within the Terminal window.
Please note that, on the MSP430G2 LaunchPad and the chipKIT Uno32, the debugging session interferes with the output to the serial console. Don't use
Serial.print() or similar on your project.
On the other LaunchPads, the serial console is not affected by the debugging session, as the USB connection acts as a hub for the programmer, the debugger and the serial console.
The debugger for chipKIT boards only allows ignoring the breakpoint a certain number of times, but not setting a condition for the breakpoint. Similarly, it doesn't support the association of an action to a breakpoint.
The Debug target turns code optimisation off, so the resulting executable file may be bigger than when compiled with another target.
Once the debugging session is ended, some boards require a specific procedure to return to the initial mode. For more information,
- Please refer to Restore Initial Mode on Specific Boards .