Skip to content

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, an ESP32 board with the external ESP-Prog programmer-debugger 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:

Platform Board Debugger Connection
Adafruit Adafruit Feather M0 Segger J-Link 2x5 0.5” SWD
Feather nRF52832 Segger J-Link 2x5 0.5” SWD
Feather nRF52840 Segger J-Link 2x5 0.5” SWD
Arduino Arduino M0 Pro and Zero On-board Programmer USB
Arduino Primo On-board USB
Arduino Due Segger J-Link 2x5 0.5” SWD
BBC BBC micro:bit On-board USB
chipKIT chipKIT Uno32 chipKIT PGM 6x1
Espressif  ESP32 Pico  ESP-Prog USB
Intel Edison with Yocto environment On-board WiFi or Ethernet over USB
LaunchPad LaunchPad MSP430G2, MSP430F5529 On-board USB
LaunchPad LaunchPad LM4F120 now TM4C123 On-board USB
LaunchPad MSP432, CC32xx and CC13xx On-board USB
Microsoft Microsoft Azure IoT DevKit On-board USB
RasPiArduino Raspberry Pi On-board WiFi or Ethernet
Seeeduino Xiao M0 Segger J-Link
STM32duino Nucleo-F401RE On-board USB

Other boards may support debugging but haven’t been tested.

For more information on how to install the tools,

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,

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 LaunchPad boards, 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 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,

Authorise the debugger

macOS requires to set special permissions to the debugger before using it: this is done by code-signing the debugger.

  • Launch Keychain Access.

  • Call the menu Keychain Access > Certificate Assistant > Create a Certificate….

  • Enter a name, for example gdb-cert.

  • Set Identity Type to Self Signed Root.

  • Set Certificate Type to Code Signing.

  • Click on Create.

Once created,

  • Search for the certificate and double-click on it.

  • Set When using this certificate to Always Trust.

  • Close the window and reboot the Mac.

After rebooting,

  • Open a Terminal window.

  • Launch

codesign -f -s  "gdb-cert" ~/Library/Energia15/packages/energia/tools/arm-none-eabi-gcc/8.3.1-20190703/bin/arm-none-eabi-gdb  

where "gdb-cert" is the name of the certificate previsouly created and ~/Library/Energia15/packages/energia/tools/arm-none-eabi-gcc/8.3.1-20190703/bin/arm-none-eabi-gdb the full path to arm-none-eabi-gdb.

For more information,