rei-forks
/
InfiniTime
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
InfiniTime/docs/build-flash-and-debug/index.md

13 KiB
Raw Permalink Blame History

Build, flash and debug

Project branches

Versioning

Files included in the release notes

Build the project

Dependencies

To build this project, you'll need:

  • A cross-compiler : ARM-GCC (9-2020-q2-update)

  • The NRF52 SDK 15.3.0 : nRF-SDK v15.3.0

  • The Python 3 modules cbor, intelhex, click and cryptography modules for the mcuboot tool (see requirements.txt)

  • To keep the system clean, you can install python modules into a python virtual environment (venv)

    python -m venv .venv
source .venv/bin/activate
python -m pip install wheel
python -m pip install -r tools/mcuboot/requirements.txt

  • A reasonably recent version of CMake (I use 3.16.5)

Note that you do not need to install those dependencies on your system if you use Docker to build the project.

Using the command line

Build steps

Clone the repo

Clone the repo and update the submodules:

git clone https://github.com/InfiniTimeOrg/InfiniTime.git
cd InfiniTime
git submodule update --init
mkdir build
cd build
Generate the project with CMake

Run CMake to generate the project. Here's the default command line

cmake -DARM_NONE_EABI_TOOLCHAIN_PATH=/path/to/the/toolchain -DNRF5_SDK_PATH=/path/to/the/sdk ..

You can specify a few more options:

  • -DCMAKE_BUILD_TYPE : specify the build type (Release or Debug). The Release mode is selected by default. It enables various optimizations from the compiler to reduce the binary size and increase perfromances. Debug mode does not enable those optimizations. It makes the binary easier to debug but it'll run slower and the binary file will be bigger.
  • -DBUILD_DFU : enables (1) or disables (0) the generation of the DFU file (needed for this OTA udate). Note that this option needs adafruit-nrfutil installed on your system.

Build

Run make to build the project:

make -j

This command will build all the targets of the project (see below). You can also specify a specific target you want to build:

make -j pinetime-mcuboot-app

Here's the list of CMake targets:

  • pinetime-app
  • pinetime-mcuboot-app
  • pinetime-recovery
  • pinetime-mcuboot-recovery
  • pinetime-recovery-loader
  • pinetime-mcuboot-recovery-loader

Binary files are generated in the src/ subfolder.

These files are named with various extensions:

  • .bin files are binary files corresponding to the firmware. These files are intended to be ran by the MCU of the PineTime.
  • .hex files are binary files formatted in the Intel HEX format.
  • .map files contains the memory mapping generated by the compiler. Useful to understand the memory usage and mapping of the firmware.
  • .out files are intended to be used by a debugger (GDB) to debug the firmware running on the PineTime

You'll find various files named according to their respective cmake target:

  • pinetime-app : The standalone version of the firmware. This firmware must be flashed at offset 0x00 and runs without the bootloader. You can use this binary to debug (using a SWD debugger) the firmware faster and more easily as it doesn't rely on the bootloader.
  • pinetime-mcuboot-app : The firmware with support for the bootloader. The file pinetime-mcuboot-app-x.y.z.bin must be converted into an MCUBoot image for the bootloader to be able to run it. This image is named pinetime-mcuboot-app-image-x-y-z.bin and it can be flashed at offset 0x8000. A DFU file for the OTA update is also generated (if the option BUILD_DFU was enabled during cmake generation) : pinetime-mcuboot-app-dfu-x.y.z.zip.
  • pinetime-recovery is the recovery firmware (standalone).
  • pinetime-mcuboot-recovery is the bootloader variant of the recovery firmware. The MCUBoot image (pinetime-mcuboot-recovery-image) and the DFU file (pinetime-mcboot-recovery-dfu) are also generated.
  • pinetime-recovery-loader is a firmware that updates the bootloader of the PineTime. Use this firmware with caution as it erases and overwrites the bootloader of your PineTime. There's no fallback in case of issue during this operation. The MCUBoot image and DFU file are also generated.

Most of the time, you'll only need the file pinetime-mcuboot-app-image to update the firmware using a SWD debugger or the file pinetime=-mcuboot-app-dfu to update it over the air using a BLE device.

See below for more info on flashing and upgrading your firmware on your PineTime.

Using docker

A Docker image (Dockerfile) containing all the build environment is available for X86_64 and AMD64 architectures. These images make the build of the firmware and the generation of the DFU file for OTA quite easy, as well as preventing clashes with any other toolchains or development environments you may have installed.

Based on Ubuntu 18.04 with the following build dependencies:

  • ARM GCC Toolchain
  • nRF SDK
  • MCUBoot
  • adafruit-nrfutil

Run a container to build the project

The infinitime-build image contains all the dependencies you need. The default CMD will compile sources found in /sources, so you need only mount your code.

Before continuing, make sure you first build the image as indicated in the Build the image section, or check the Using the image from Docker Hub section if you prefer to use a pre-made image.

This example will build the firmware, generate the MCUBoot image and generate the DFU file. For cloning the repo, see these instructions. Outputs will be written to <project_root>/build/output:

cd <project_root> # e.g. cd ./work/Pinetime
docker run --rm -it -v $(pwd):/sources infinitime-build

If you only want to build a single CMake target, you can pass it in as the first parameter to the build script. This means calling the script explicitly as it will override the CMD. Here's an example For pinetime-app:

docker run --rm -it -v $(pwd):/sources infinitime-build /opt/build.sh pinetime-app

The image is built using 1000:1000 for the user id and group id. If this is different to your user or group ids (run id -u and id -g to find out what your id values are if you are unsure), you will need to override them via the --user parameter in order to prevent permission errors with the output files (and the cmake build cache).

Running with this image is the same as above, you just specify the ids to docker run:

docker run --rm -it -v $(pwd):/sources --user $(id -u):$(id -g) infinitime-build

Or you can specify your user id and group id (by number, not by name) directly:

docker run --rm -it -v $(pwd):/sources --user 1234:1234 infinitime-build

Using the image from Docker Hub

NOTE : This image is provided by a contributor and might not be up-to-date.

The image is available via Docker Hub for both the amd64 and arm64v8 architectures at pfeerick/infinitime-build.

It can be pulled (downloaded) using the following command:

docker pull pfeerick/infinitime-build

The default latest tag should automatically identify the correct image architecture, but if for some reason Docker does not, you can specify it manually:

  • For AMD64 (x86_64) systems: docker pull pfeerick/infinitime-build:amd64

  • For ARM64v8 (ARM64/aarch64) systems: docker pull pfeerick/infinitime-build:arm64v8

Build the image

You can build the image yourself if you like!

The following commands must be run from the root of the project. This operation will take some time but, when done, a new image named infinitime-build is available.

docker image build -t infinitime-build ./docker

The PUID and PGID build arguments are used to set the user and group ids used in the container, meaning you will not need to specify it later unless they change for some reason. Specifying them is not mandatory, as this can be over-ridden at build time via the --user flag, but doing so will make the command you need to run later a bit shorter. In the below examples, they are set to your current user id and group id automatically. You can specify them manually, but they must be specified by number, not by name.

docker image build -t infinitime-build --build-arg PUID=$(id -u) --build-arg PGID=$(id -g) ./docker

Using VSCode

The .VS Code folder contains configuration files for developing InfiniTime with VS Code. Effort was made to have these rely on Environment variables instead of hardcoded paths.

At the moment building using VSCode on Windows has not been done yet. Using the devcontainer is probably the easiest way.

Environment Setup

To support as many setups as possible the VS Code configuration files expect there to be certain environment variables to be set.

Variable Description Example
ARM_NONE_EABI_TOOLCHAIN_PATH path to the toolchain directory export ARM_NONE_EABI_TOOLCHAIN_PATH=/opt/gcc-arm-none-eabi-9-2020-q2-update
NRF5_SDK_PATH path to the NRF52 SDK export NRF5_SDK_PATH=/opt/nRF5_SDK_15.3.0_59ac345

VS Code Extensions

We leverage a few VS Code extensions for ease of development.

Required Extensions
  • C/C++ - C/C++ IntelliSense, debugging, and code browsing.
  • CMake Tools - Extended CMake support in Visual Studio Code
Optional Extensions

Cortex-Debug - ARM Cortex-M GDB Debugger support for VS Code

Cortex-Debug is only required for interactive debugging using VS Codes built in GDB support.

VS Code/Docker DevContainer

The .devcontainer folder contains the configuration and scripts for using a Docker dev container for building InfiniTime

Using the Remote-Containers extension is recommended. It will handle configuring the Docker virtual machine and setting everything up.

More documentation is available in the readme in .devcontainer

DevContainer on Ubuntu

To use the DevContainer configuration on Ubuntu based systems two changes need to be made:

  1. Modify the file .devcontainer/devcontainer.json and add the argument "--net=host" to the "runArgs" parameter making the line look like this: "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined", "--net=host"],
  2. Modify the file .vscode/launch.json and change the argument of "gdbTarget" to "127.0.0.1:3333", making the line look like: "gdbTarget": "127.0.0.1:3333",
  3. To start debugging launch openocd on your host system with the appropriate configuration, for example with a stlink-v2 the command is: openocd -f interface/stlink.cfg -f target/nrf52.cfg. This launches openocd with the default ports 3333, 4444 and 6666.
  4. In VsCode go to the Debug pane on the left of the screen and select the configuration Debug - Openocd docker Remote and hit the play button on the left.
Dev Container on Windows

To use the DevContainer configuration on Windows a few files need their line endings changed, e.g. by using notepad++

\InfiniTime\tools\mcuboot\imgtool.py
\InfiniTime\tools\mcuboot\imgtool_init_.py
\InfiniTime\tools\mcuboot\imgtool\boot_record.py
\InfiniTime\tools\mcuboot\imgtool\image.py
\InfiniTime\tools\mcuboot\imgtool\version.py

You also need to install cbor with pip install cbor or by running pip install -r requirements.txt in \Infitime\tools\mcuboot.

Build the documentation

Setup

The documentation is written in Markdown (.md) files and generated using the Sphinx documentation generator.

First, we need to install Sphinx and its dependencies:

  • myst-parser : add support for markdown files
  • sphinx_rtd_theme : theme from ReadTheDocs
pip install sphinx
pip install myst-parser
pip install sphinx_rtd_theme

Build the doc

Run the following command in the folder docs

sphinx-build -b html ./ ./generated

Then display the doc by browsing to generated/index.html using your favorite web browser.

Flash the firmware using OpenOCD and STLinkV2

Build the project with Docker

Build the project with VSCode

Bootloader, OTA and DFU

Stub using NRF52-DK

Logging with JLink RTT

Using files from the releases