A devcontainer for the Raspberry Pi Pico on Ubuntu 20.04

When developing for different processors I like to use dev containers since they serve to keep all the necessary tools and libraries isolated in a nice, clean sandbox. So when I wanted to set up a development environment for the Raspberry Pi Pico it was only natural to look around and see what was available.

I found a really nice one put together by Matthew Winters that includes all the tools of interest, including openocd for debugging. The container built but there were a few problems. After some investigation I was able to track down the solutions and I’m documenting them here, if only for myself.

Fixing the nm-multiarch ENOENT Problem

For development and debugging, I’m using the hardware hookup described in this DigiKey article. I had previously build picotool and loaded it into a second Raspberry
Pi Pico but when I tried to debug a sample program I got an error related to nm-multiarch. I found the solution in this thread on the Raspberry Pi forum.

To fix it, navigate to the .devcontainer folder open the Dockerfile file in a text editor. Add binutils-multiarch to the list of packages to be installed and add the line:

    RUN cd /usr/bin && \
        ln -s /usr/bin/objdump objdump-multiarch && \
        ln -s /usr/bin/nm nm-multiarch 

to the end of the file. So now the Dockerfile looks like:

    ARG VARIANT="ubuntu-20.04"
    FROM mcr.microsoft.com/vscode/devcontainers/cpp:0-${VARIANT}

    RUN apt-get update && \
        export DEBIAN_FRONTEND=noninteractive && \
        apt-get -y install --no-install-recommends \
            cmake \
            build-essential \
            wget \
            ca-certificates \
            gdb-multiarch \
            binutils-multiarch \
            automake \
            autoconf \
            libtool \
            libftdi-dev \
            libusb-1.0-0-dev \
            pkg-config \
            clang-format
    WORKDIR /apps
    RUN wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 && \ 
        tar xjf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 
    RUN mv gcc-arm-none-eabi-10.3-2021.10 gcc-arm-none && \
        ln -s /apps/gcc-arm-none/bin/arm-none-eabi-gcc /usr/bin/arm-none-eabi-gcc && \
        rm gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 
    ENV PATH=$PATH:/apps/gcc-arm-none/bin
    RUN git clone -b master https://github.com/raspberrypi/pico-sdk.git --depth=1 && cd pico-sdk && git submodule update --init 
    ENV PICO_SDK_PATH=/apps/pico-sdk
    RUN git clone https://github.com/raspberrypi/openocd.git -b picoprobe --depth=1 && \
        cd openocd && ./bootstrap && ./configure --enable-ftdi --enable-sysfsgpio --enable-picoprobe && make -j 8 install && \
        cd /apps && git clone https://github.com/raspberrypi/picotool.git --depth=1 && \
        cd picotool && mkdir build && cd build && cmake ../ && make -j 8 && cp picotool /usr/local/bin && \
        cd /apps && git clone https://github.com/wtarreau/bootterm.git --depth=1 && \
        cd bootterm && make -j 8 install 
    RUN cd /usr/bin && \
        ln -s /usr/bin/objdump objdump-multiarch && \
        ln -s /usr/bin/nm nm-multiarch 

Accessing the USB Port

The next problem was accessing picoprobe via the USB port. For some reason the board running picoprobe wasn’t visible from within the container even though it enumerated on the host operating system.

The solution to this is to mount the /dev/bus/usb folder using the volumes option and privileged mode.

Open the devcontainer.json file in the .devcontainer folder and add the options –privileged, -v, /dev/bus/usb:/dev/bus/usb to the runArgs block. So now the runArgs block looks like:

    "runArgs": [
        "--cap-add=SYS_PTRACE",
        "--security-opt",
        "seccomp=unconfined",
        "--privileged",
        "-v", "/dev/bus/usb:/dev/bus/usb",
        "--device=/dev/bus/usb",
        "--device=/dev/ttyACM0"
    ],

It should be noted that running a container in privileged mode is insecure and is generally frowned upon, but I’m the only one who will be using this container so I consider it a fair trade.

Deprecated Option in Cortex-Debug

The final change I made is more of a suggestion. Apparently the runToMain option in the VSCode Cortex-Debug extension has been deprecated. To fix this warning navigate to the .vscode folder and open the launch.json file. In the configurations block, replace the line

    "runToMain": true

with

    "runToEntryPoint": "main"

where “main” represents your programs entry point.

Now you can open and rebuild the container as described on the original devcontainer page.

Conclusions

Thanks to Matthew Winters for his work on the original devcontainer. Not having to start from scratch to develop for the pico really simplified things.

If you’re interested you can download the original container from Matthew’s GitHub repo and make the changes yourself. Otherwise I’ve made a fork of Matthew’s repo with the changes described above available here.

• Posted in: Uncategorized
• Tagged: Embedded programming, RaspberryPi