• Software Development
• Education

Contents:

• Introduction
• Setup
• Hardware
• Workstation
• Software Checks
• USB Device
• Minicom
• JLinkExe
• FTHR840BOOT Contents
• OpenOCD
• VolksEEG/eeg-device-firmware
• PR "Merging initial implementation of the PC communications interface"
• Container
• Container Build Failure
• Container Build Fix
• Opened Container
• Debugging
• TERMINAL gdb-server Output
• DEBUG CONSOLE Output
• Running Application
• Test Modifications
• Serial Output
• Semihosting Output

Introduction

In this post, I'll show you how to do Rust development on a new Adafruit Feather nRF52840 Express board, using the initial VolksEEG Project prototype application.

I used Ubuntu 20.04. However, because development takes place under VS Code running in a Docker container, you should be able to follow the same procedure on other development platforms with only minor platform-specific tweaks.

The application is based on a Rust RTIC (Real-Time Interrupt-driven Concurrency) demonstration app. Once the board has been flashed with the application, it runs as a serial echo-server. This is a nice way to prove out the development environment and device USB path, and have a playground for experimenting with Rust and RTIC.

This builds on wiki pages and code in the VolksEEG repo contributed by other project participants:

• Harry Brown: Guide for VS Code/PlatformIO at Feather Setup Guide (while I don't use PlatformIO in this post, this wiki page has helpful setup information for working with the Adafruit Feather nRF52840 Sense variant of the board).
• Kevin Nause: Initial VS Code/Docker/Rust/RTIC example at Nauscar/nrf52-fw-demo.
• Graham Long: Initial echo-server application at VolksEEG/eeg-device-firmware/pull/2.

A big thank you to them for providing all the source material so I could learn how to do this!

I don't know much about working with Docker, so that's another learning curve along with the other parts here. Given that this environment uses tools layered on top of tools, it can be challenging to diagnose and fix the problem when a failure occurs. I've included a container build failure and its fix as an example of how to address one such problem.

Setup

Hardware

• Adafruit Feather nRF52840 Express (Product ID: 4062)
• SEGGER J-Link EDU Mini - JTAG/SWD Debugger (Product ID: 3571)

Reference information:

• Introducing the Adafruit nRF52840 Feather

Workstation

I'm running Ubuntu 20.04 x86_64 on a low-cost HP-14-dq0xxx laptop (Intel® Celeron(R) N4020 CPU @ 1.10GHz × 2, 4 GB RAM, 64 GB eMMC). This is a very low-end system, but has been sufficient so far.

Software Installed:

• J-Link Software and Documentation Pack
• VS Code
• Docker

Workstation:

Board with USB and J-Link, powered up:

Closeup of board, powered down:

Software Checks

These verify basic board connection and operation.

USB Device

Minicom

This connects to the board USB and shows the output of the pre-loaded flash image running on the board as it comes from Adafruit:

JLinkExe

This connects over the J-Link debugger, via the SWD target interface:

The board does not support JTAG. Attempting to connect via JTAG causes the FTHR840BOOT device to auto-mount after several seconds; it automatically disconnects after 5 minutes. (The Adafruit Update Bootloader section says to double-click the reset button to get to this bootloader drive normally).

FTHR840BOOT Contents

OpenOCD

Run in a separate terminal. A quick breakdown of the command:

• The debug interface to the board is via J-Link (vs. for example, ST-Link).
• The transport protocol is SWD (vs. for example, JTAG).
• The target device is in the nRF52 series (vs. for example, STM32).

VolksEEG/eeg-device-firmware

Repo: VolksEEG/eeg-device-firmware (forked from VolksEEG)

PR "Merging initial implementation of the PC communications interface"

Pull Request #2

This version of the application is a simple serial echo-server: it opens a USB serial device and echoes any characters received. This is the intial prototype of the PC interface to stream EEG data to a USB-connected PC.

Container

Using VS Code, open this repo in a Dev Container (see Developing inside a Container). The container includes the Rust tools, including probe-rs, which allows debugging with a J-Link pod via OpenOCD over SWD. Everything is setup to run on a Nordic nRF52840_xxAA device.

The .devcontainer/ directory contains two files that configure the environment, providing VS Code extensions and Linux tools:

• devcontainer.json configures VS Code to run in the container.
• Dockerfile configures the container for Docker.

When you open the folder in a container for the first time, VS Code creates the container. This builds all the resources listed in the configuration.

Container Build Failure

Building the container initially fails. This serves as a useful example of what to do in this situation.

This is because the hidapi crate requires the libudev library, which is not provided by default.

Container Build Fix

Fix the build by adding libudev-dev to the Dockerfile apt-get install command:

This results in a successful open of the container.

Opened Container

All subsequent operations take place in VS Code in the container.

Debugging

The VS Code debugger interface runs probe-rs, which runs OpenOCD (with gdb-server) and gdb.

File openocd.cfg selects the J-Link interface with SWD transport, for an nRF52 target.

This opens the VS Code debugger GUI (see Visual Studio Code: Debugging), including the source code pane, with the following outputs:

• DEBUG CONSOLE: gdb terminal interface.
• TERMINAL Cargo Build (debug): Rust build output.
• TERMINAL gdb-server: OpenOCD output.

You can use the VS Code debugger source pane to set breakpoints. You can use the debugger GUI toolbar to run the code or step through it.

Processes:

TERMINAL gdb-server Output

DEBUG CONSOLE Output

Running Application

In the source code, file volks-fw/src/main.rs defines a USB device builder:

Device Hunt lists this USB Vendor ID/Product ID pair as:

When the application runs, the device identifies itself as this:

Running minicom on the device results in echoing any input:

Test Modifications

I made the following modifications to add my username to the program output to prove signs of life end-to-end through the toolchain (see Dumb Embedded System Mistakes: Running The Wrong Code for why I do this).

Serial Output

This change adds the username to the serial echo output:

Minicom output:

Semihosting Output

Semihosting sends output over the debugger connection to the host debug serial output, in this case over the J-Link to the OpenOCD terminal, via the hprintln! macro (see Semihosting - The Embedded Rust Book). This allows you to print debug messages without using the board's USB connection.

Changes:

To see the output, you first need to enable semihosting in OpenOCD, with the mon arm semihosting enable command in the DEBUG CONSOLE:

If you forget to enable semihosting, the debugger will break at __c_m_sh_syscall@0x00003cee (Unknown Source:0). You can enable semihosting at that point and continue.

TERMINAL gdb-server output:

Sign in