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:

ebay_board.cfg

set CHIPNAME STM32F103C8T6

source [find interface/stlink-v2.cfg]

transport select hla_swd

set WORKAREASIZE 0x2000
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
        http://openocd.org/doc/doxygen/bugs.html
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
        http://openocd.org/doc/doxygen/bugs.html
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:

cd
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.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/ARM/gcc-arm-none-eabi-6_2-2016q4/bin/../lib/gcc/arm-none-eabi/6.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: /tmp/jenkins-GCC-6-build...
...
...

Success!

OpenOCD
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:

ESP8266 SDK

$ cd /opt
$ git clone --recursive https://github.com/pfalcon/esp-open-sdk.git
$ cd esp-open-sdk
$ make STANDALONE=y

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 https://github.com/anakod/Sming.git

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: 
# COM_PORT = COM3

# 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 Makefile-user.mk 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 esptool.py 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/esptool.py", line 135
    print 'Connecting...'
                        ^
SyntaxError: Missing parentheses in call to 'print'
/opt/Sming/Sming/Makefile-project.mk:274: recipe for target 'out/build/app.out' failed
make: *** [out/build/app.out] Error 1

So we need to edit the esptool.py 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 miniterm.py 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.

Edit:
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 Makefile-user.mk 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 http://www.nbandroid.org/

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…