Using the Blackmagic probe with Netbeans

Using the Blackmagic debug probe (BMP) with Netbeans is very similar when doing the same but with using Openocd.

The initial steps are the same to use the BMP probe and Openocd. First we set up the ARM toolchain or other, as needed. We also need the gdbserver plugin for Netbeans, and so, we also need to install it. After these two initial steps, the remaining configuration and how to use the probe differs a bit differently from when using Openocd.

One of the main differences is that with Openocd, externally we launch an instance of Openocd and then use the Netbeans gdbserver plugin to connect to that openocd instance. For that we use the Netbeans menu Debug and Attach Debugger and use connection string extended-remote localhost:3333 and the selected project:

For using the BMP probe we don’t need no intermediary software since the code supporting the gdbserver plugin is already on the probe firmware, which means that the debugger can connect directly to the target. In fact due to this we do not need now to attach to a debugger and we can start using the Debug Project (CTRL-F5) to program/flash the code output (optional) and to start debugging the code running on the target device.

For this to happen we need to configure the Debug Command for the project (this must be done for each project if needed) and if wanted we can also configure the Run Command.
Before we are able to do that, we need first to create a command file for the gdb debugger that will pre-execute some commands, namely to attach to the targets probe, before starting the debugging session.

For that I’ve created a file named BMPgdbinit located, in my case, in /opt/ARM:

target extended-remote /dev/ttyACM0
monitor swdp_scan
att 1

This file is invoked by the ARM debugger toolchain (like this: arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit file.out) and it will connect to the Blackmagic probe, that should be located at /dev/ttyACM0, scan the SWD searching for the device, attaches to it, loads/programs the output file, namely the firmware, and starts it. From this point the gdbserver from Netbeans takes control and should stop at the first line of code or the first break point.

So to configure the run command we edit the Project Properties and modify the Run command:

Just define the Run Command as arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit “${OUTPUT_PATH}”

With this configuration we can now press F6 to flash our firmware (because the load command is on the BMPgdbinit file) and run it.

For debugging we need the following configuration:

We must define the Debug Command as ${OUTPUT_PATH} since this will be passed as the arm-none-eabi-gdb file parameter.
We also need to point to the correct location of the BMPgdbinit file.

We can now just press CTRL-F5 to launch a debug session, and again, the firmware will be loaded, and the code will stop at the first break point.

An example of using Netbeans to build a simple program targeting the nRF52832 (the blinky example from pcbreflux ) with an added variable and a watch point set:

That’s it….


There are some issues with the above process…

Can’t stop the debugger. Pressing Pause does nothing…
This is a long standing bug apparently so the solution is on a external terminal window send a SIGINT signal to the gdb process:

[pcortex@pcortex:~]$ ps -ef | grep arm-none
pcortex 9792  9405  0 20:22 ?        00:00:00 /tmp/dlight_fdam/5fe1c993/0397644155/pty --dir /opt/nordic/nRF52832/blinky --no-pty /opt/ARM/gcc-arm-none-eabi-6_2-2016q4/bin/arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit -nx --interpreter mi -tty /dev/pts/7
pcortex 9794  9792  0 20:22 ttyACM0  00:00:00 /opt/ARM/gcc-arm-none-eabi-6_2-2016q4/bin/arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit -nx --interpreter mi -tty /dev/pts/7

Just send a SIGINT signal to the process associated to the Blackmagic probe:

kill -SIGINT 9794

The control is returned to Netbeans.

The debugger doesn’t seem to follow my code…
Just Clean and build all the project and select run so a clean version of the program is flashed.

I unplug and plug the probe a lot and the tty ports change..

Because of this the BMPgdbinit script can be broken because the probe port changes, for example, to /dev/ttyACM2.

The solution is to create a rules file:

Mine, for Arch Linux is as follows:

# Black Magic Probe
# there are two connections, one for GDB and one for uart debugging
  SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic GDB Server", SYMLINK+="ttyBMP"
  SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic UART Port", SYMLINK+="ttyBMPUART"

This file is named 99-blackmagic.rules located at /etc/udev/rules.d.

We now need to change the port used on the BMPgdbinit file from /dev/ttyACM0 to /dev/ttyBMP. Note that after plugging in the probe to the USB port, it takes a while (2 to 3 seconds) to the ports appear.

This just doesn’t work…

Yes, some times the behaviour seems strange… I’ve worked around some of the issues by flashing again the softdevice and the program mannually from the GDB command line.

Also if something like this happens:

It is due to the fact that the Netbeans environment variables $OUTPUT_PATH is empty… The solution is to explicitly state the outputfile on the RUN and Debug commands instead of using the ENV var. For example change this:

arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit "${OUTPUT_PATH}"

to this

arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit /opt/Projects/nRF/proj1/program.out

or to this:

arm-none-eabi-gdb -x /opt/ARM/BMPgdbinit "${PROJECT_DIR}/file.out"

Final note:
As a final note, some other errors might creep up like:

  • Program is not being run: Check the command line of arm-none-eabi-gdb to see if the BMPgdbinit file is correctly provided.
  • Don’t know how to run. Try \”help target\”.: Same issue. Check if the run and debug commands are correctly defined.
  • Sometimes my target isn’t detected.: Adding an extra monitor swdp_scan line to the BMPgdbinit file might help.

Using Netbeans, OpenOCD and GDBServer plugin for ARM development

On my previous post we’ve seen how to setup the base software for starting up programming for ARM processor based boards.

Normally these boards have no base code running, like Arduino for example, to allow direct programming through USB, and so we need to have a programmer to flash the code onto the board through a specific interface, either JTAG or SWD. As a bonus the programmer also allows to debug in real time the code on the processor with breakpoints and watchpoints without resourcing to the common printf or Serial.print…

These programmers come on all sizes, shapes and prices… Some of the available are:

  1. STLink/V2 – Standard programmer from 2.5€ and up for clones, 22€ for the original.
  2. BlackMagic probe – An alternative that can be flashed on some hardware to build programmers, and that supports some devices based on the ARM processors, for example the BLE NRF51822 chip.
  3. Segger J-Link – State of the art programmer. A cheaper EDU version is available but with some licensing restrictions.

STLink/V2 is supported by OpenOCD which allows to use openocd to flash and debug code through JTAG or SWD (Single Wire Debug).

Code Sample
The “Hello World” example on the hardware world is the Blink Led example. On this site there is an example for my processor, in my case the STM32F103 processor. Just download and expand the file and import the project into NetBeans:

New Project with existing sources

Just make sure that the correct toolchain is selected:

Project with ARM Toolchain

The build process should run without errors, and at the root of the project a new file should be created: main.elf

Flashing the code
For using OpenOCD to flash the code onto the ARM processor based board we need to configure openocd to know which programmer is using and which target board is programming.
In my case since I’m using a STLink/V2 programmer connected to a target STM32F103 based board, I’ve created the following configuration file:


source [find interface/stlink-v2.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]

Based on this configuration we can flash now our board:

openocd -f /opt/ARM/ebay_board.cfg -c init -c targets -c "halt" -c "flash write_image erase /opt/ARM/Projects/STM32F103VHB6_RevZ_Demo1/main.elf" -c "verify_image /opt/ARM/Projects/STM32F103VHB6_RevZ_Demo1/main.elf" -c "reset run" -c shutdown

And the output is:

Open On-Chip Debugger 0.9.0 (2016-04-27-23:18)
Licensed under GNU GPL v2
For bug reports, read
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.208372
Info : STM32F103C8T6.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* STM32F103C8T6.cpu  hla_target little STM32F103C8T6.cpu  halted
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004fd0
wrote 7168 bytes from file /opt/ARM/Projects/STM32F103VHB6_RevZ_Demo1/main.elf in 0.468006s (14.957 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20004fd0
verified 6836 bytes in 0.035336s (188.923 KiB/s)
shutdown command invoked

Success! A blinking led (we have to connect one on my board to the correct pin) is now blinking.

Debugging the code:
To be able to debug our code we need to start OpenOCD and connect it to the board:

openocd -f ebay_board.cfg 
Open On-Chip Debugger 0.9.0 (2016-04-27-23:18)
Licensed under GNU GPL v2
For bug reports, read
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.211511
Info : STM32F103C8T6.cpu: hardware has 6 breakpoints, 4 watchpoints

And openocd is running.

On the NetBeans size we need to goto Debug->Attach Debugger. A new window should appear and we must change the debugger type from the default GDB Debugger to gdbserver and configure the openocd remote port and project:

gdbserver configuration

Make sure that the target is defined as: extended-remote localhost:3333
and the correct project is selected.

And that’s it. If the code already has some breakpoint defined, and the code passes through it, the execution is stopped and the correct code line is shown. Otherwise we can press the Pause button:

Debugger control

On the openocd output we can see the breakpoints and code pause working:

Info : device id = 0x20036410
Info : flash size = 64kbytes
Info : halted: PC: 0x08000806

Hardware breakpoint

If there are weird errors regarding connection dropped or failed, make sure that under the toolchain for ARM, the correct debugger is selected, meaning it should be the ARM debugger and not the gdb debugger.

And that’s it.

Setting up Netbeans for ARM development

My quick notes for setting up Netbeans, OpenOCD for ARM cortex processor development on Arch Linux. The instructions, excluding the ARCH Linux specific pacman commands, should be the same for any Linux platform.

So I’ve bought some STM32F103 ARM Cortex based boards, and for starting building software for them these are the steps:

Arm toolchain

Download the ARM toolchain from ARM GNU Toolchain. In my case I downloaded the latest available version for Linux 64 bit.

Create a working directory, in my case I just created /opt/ARM and unzip the toolchain there.

cd /opt
mkdir ARM
cd ARM
tar xvf ~/Downloads/gcc-arm-none-eabi-6_2-2016q4-20161216-linux.tar.bz2

Add now the ARM toolchain to your path, by editing the .bashrc file at our home directory:

vi .bashrc

Add at the end the following line:

export PATH=$PATH:/opt/ARM/gcc-arm-none-eabi-6_2-2016q4/bin

and then execute the following command for assuming the new setting, on the current terminal window:

source ~/.bashrc

To the new path to be globally available we have to logout and login again, but we won’t do that right now.

We can now test the ARM toolchain installation by calling, for example the command: arm-none-eabi-gcc -v

arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /tmp/jenkins-GCC-6-build...


OpenOCD is a tool that will allow to flash the ARM processors and also allow to debug code. Netbeans by itself won’t be able to flash code on the processor. So regarding OpenOCD we need to do the installation and some configurations first:

On ARCH Linux it goes more or less like this:

sudo -s
pacman -S openocd
cp /usr/share/openocd/contrib/99-openocd.rules /etc/udev/rules.d

groupadd plugdev
usermod -a -G plugdev pcortex

udevadm control --reload-rules

Replace pcortex on the usermod command with your user name. Now we can logout and logon again to assume the new user group and path.

Setting up Netbeans
After starting up NetBeans, I’m using the latest version 8.2 (at the date of this post), we select Tools->Plugins and try to search and install the gdbserver plugin. If it fails searching for it, just download it from the GDBServer Plugin home page and install it manually.

Then we need to add the ARM toolchain to the available C++ Tools Collection. Just go to Tools->Options->C++ and press the Add button:

Add ARM Toolchain

Then add the correct path to the binaries for C/C++ and very important for the ARM debugger:
ARM tools

We don’t need to do nothing for anything else, since Code Completion tab will be filled automatically.

And that’s it, we can now use Netbeans to develop for ARM based boards.

In the next post we will see how to flash and debug code on these ARM based boards.

ESP8266 – Setting up Sming and NetBeans

Sming is one of the alternative firmware for the ESP8266 that is built on top of an extensive library that hides some of the ESP8266 SDK complexities. There is also another alternative firmware that is directly integrated with the Arduino IDE ESP8266 Arduino that mimics much of the process and ways off building Arduino sketchs that deploy and run on the ESP8266.

I’ve tried both, and for my tastes, since I prefer Netbeans or other editor to the Arduino IDE, I’ve choose to use the Sming firmware.

Setting up the SDK and Sming
For starting to use the Sming firmware, we should download the ESP8266 SDK and Sming from Github. The pfalcon esp-open-sdk is the fastest way to set up the SDK. Just do:


$ cd /opt
$ git clone --recursive
$ cd esp-open-sdk

Make sure for running the above commands that you have the prerequisites installed for your platform.
The make command will take a while depending of your internet speed and machine speed. It can take around 20 minutes or more.

For installing Sming, the Github site instructions explain what is needed. Basically it’s:

$ cd /opt
$ git clone

To use Sming we need to set our environment variables.

$ export ESP_HOME="/opt/esp-open-sdk";
$ export SMING_HOME="/opt/Sming/Sming";

But this change is not permanent and it won’t work with Netbeans without changing the Makefiles.
So we need to change the core Makefile to add permanently the paths to the SDK and SMING homes:

Set Sming environment paths permanently:
Just got to Sming home directory /opt/Sming/Sming and edit the file Makefile:

Change the lines (uncomment them, removing the #):

## Defaults for Sming Core

## ESP_HOME sets the path where ESP tools and SDK are located.
## Windows:
# ESP_HOME = c:/Espressif

## MacOS / Linux:
ESP_HOME = /opt/esp-open-sdk

## SMING_HOME sets the path where Sming framework is located.
## Windows:
# SMING_HOME = c:/tools/sming/Sming 

# MacOS / Linux
SMING_HOME = /opt/Sming/Sming

## COM port parameter is required to flash firmware correctly.
## Windows: 

# MacOS / Linux:
# COM_PORT = /dev/tty.usbserial

# Com port speed
COM_SPEED = 115200

For each project demo that we are going to compile, at the root of the project we need to change/uncomment at the file the same variables to define the same values. Otherwise Netbeans will complain that the SMING_HOME and ESP_HOME Variables are not defined. We can use the Netbeans itself to edit that file.

One final change is needed regarding the that is used by Sming to flash the ESP8266 chips. The tool is made to run with Python 2 and on my Arch Machine I have both Python 3 and Python 2, being Python 3 the default. Due to this, the esptool might fail to run with the following error:

# Generating image...
  File "/opt/esp-open-sdk/esptool/", line 135
    print 'Connecting...'
SyntaxError: Missing parentheses in call to 'print'
/opt/Sming/Sming/ recipe for target 'out/build/app.out' failed
make: *** [out/build/app.out] Error 1

So we need to edit the file and change the header to use Python2:

#!/usr/bin/env python2

Also the tool assumes that the ESP8266 is connected and available at the serial port ttyUSB0.

We can now go to one of the examples directory and compile one of the examples. Since I’m using my own developer board that uses serial RTS and DTR to enter “automagically” the ESP8266 in flash mode, I just need to do make at the root of the example directory. If needed we can flash again with the command make flash

And that’s it.
Just a word of caution, since my developer board uses the RTS and DTR lines, the Sming Make file calls the that doesn’t set the RTS and DTR lines to inactive state, and so keep the ESP8266 in reset mode. To solve this, just change the TERMINAL directory on the makefile of your platform located at Sming/Sming to something that works. EDIT: Or use CTRL-T + D and CTRL-T + R to reset the lines.

Setting Netbeans to compile with the Sming Framework
Important note/update: With the latest Netbeans 8.1 version, code completion doesn’t work. Use version 8.0.2 for now to solve the issue.

To use Netbeans, just open up Netbeans, and go to Tools->Options and select the C++ icon. If needed press the Activate button to enable C++ support.
The instructions are now very similar to those in this post Setting up Netbeans for ESP8266. Just make sure that you have the C++ plugin installed, and restart the IDE if necessary.
Then at the C++ Window Build Tools tab, just add a new Tool Collection, but this time the compiler path is /opt/esp-open-sdk/xtensa-lx106-elf, and ignore the error, but select the family as GNU. The error should be gone. Give it a name: ESP8266 Xtensa and press OK. Just set up now the path to the C compiler and C++ compiler located on the bin directory: /opt/esp-open-sdk/xtensa-lx106-elf/bin.

Netbeanx Xtensa compiler
Netbeanx Xtensa compiler

For making Netbeans Code completion work, we need to add the path to include files on the Xtensa compiler tools. Make sure that it’s the ESP8266 Xtensa compiler that is selected and add the following paths:

Include paths
Include paths

These might not be enough. It really depends on the project. Make sure that you add the include paths to both the C++ and C compiler.

I had to add the following paths at the Code Completion for the Xtensa compiler so the code completion could work without warnings on the SmingCore.h file with the latest Sming version:

  • Sming/rboot
  • Sming/rboot/appcode

Just add this directories the same way as the above screenshot.

Also at the project level properties it is necessary to add the project include directory so that the user_include.h file and others can be found.

And we are set!

Compiling Basic_Blink Project
Using Netbeans, just add a new C++ project with existing sources, and select the root directory of any of the examples, in this case, let’s choose the /opt/Sming/Basic_Blink. Just make sure that the compiler tools choosen is the ESP8266 Xtensa that we previously have defined. At start Netbeans will try to run the make command, and it might fail.
Just open on the project tree the file and remove the comment from the lines defining the ESP_HOME and SMING_HOME paths.
Also select the Makefile, right click Make target->Add target and add the word flash as a target.

That’s it, we can now make the project and select Make Target->flash to flash to the device.

Happy coding

Android SDK and NetBeans

I’m user of Netbeans for my Java related work.

The Android SDK instructions refer the use of Eclipse as the IDE of choice, but is also possible to use Netbeans with the NBAndroid plugin, available at

Just following the instructions for installing the plugin in into Netbeans, namely by adding the plugin URL and installing them.

One issue that I’ve found was that the New Project Wizard didn’t show the Android type applications for creation…

For making on the New Project Wizard the Android Projects available to be created, you must enable the JAVA ME plugin, so just go again to Plugins and select JAVA ME and press Enable at the bottom of the window.

It should work now.


[K]Ubuntu and Netbeans 6.1 with Firefox 3.0

One annoying things that took some time to solve was that on the Start page of Netbeans there are URL’s to several articles, blog posts and so one, but every time I’ve pressed one of the it say’s that it could not execute Firefox.

I’ve checked the path, permissions, and so on but with no solution.

Well the issue is quite simple:

Goto Netbeans Tools menu and select the last option Options. It should start on the general tab where you select the browser you which to use.

Select Edit and on the arguments for Firefox remove whats there: -remote “openURL({URL})” and just keep the {URL} nothing else.

Save, close and it should work.

Now back to work…