Check the configuration¶
This chapter requires the embedXcode+ edition 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 Microsoft Azure IoT DevKit board, a BBC micro:bit board, 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 Feather nRF52832 (previously named Feather nRF52) boards using the Segger J-Link emulator,
BBC micro:bit using the USB connector,
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, most of the devices with the XDS110 debug probe from the SimpleLink portfolio, including MSP432, CC32xx and CC13xx LaunchPad boards,
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, launch the debugging session while the sketch is running on the board. Depending on the board, Debug the boards with GDB on a Terminal window, Debug the boards with Ozone , or Debug the chipKIT boards with MDB on a Terminal window.
Contrary to some debuggers, breakpoints can't be changed interactively during a debugging session within the standard Xcode interface. However, this is performed with the command line interface on the Terminal window, or within the Segger Ozone application.
On the MSP430G2 LaunchPad and the chipKIT Uno32, the debugging session interferes with the output to the serial console.
- On those boards, don't use
Serial.print()or similar on your project when debugging.
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 their initial modes and configurations.
For more information,
- Please refer to Restore initial mode on specific boards .