Getting Started: Raspberry Pi Pico RP2040 with Eclipse and J-Link

In this time where many micro-controllers have 100+ weeks estimated delivery time, it makes sense to look at alternatives. So it is not a surprise that the Raspberry Pi RP2040 gets used more and more in projects. It is not only inexpensive, it is (at least for now) available which makes all the difference. The RP2040 is the first microcontroller from Raspberry Pi: a dual-core ARM Cortex-M0+ running up to 133 MHz, 264 KByte on-Chip RAM and up to 16 MByte external FLASH.

Raspberry Pi Pico with J-Link, with a NXP sensor board

It is a very versatile microcontroller, with a rich eco-system and set of tools. It can be easily used with C/C++ or MicroPython, and the Raspberry Pi Pico board only costs around $5. There are plenty of tutorials out there, for example how to use the Pico board as debug probe to debug another Pico board. While this is great, there is an easy way to use any existing J-Link and Eclipse IDE too, so this is what this article is about.

Hardware Connection

As debug probe, any J-Link can be used. I’m using here the J-Link EDU Mini which is well worth the $20.

SEGGER J-Link EDU Mini

The Raspberry Pi Pico includes a 3-pin debug header with GND, SWDIO and SWDCLK:

Because the Pico does not use a standard 2×5 pin debug header, I have to connect the pins including VCCsense with an adapter board. I’m using the JTAG/SWD breakout board from Adafruit: https://www.adafruit.com/product/2094. Additionally 4 jumper wires are needed.

Connections are as below:

Raspberry Pi Pico SWD Connection

Setup & Tools

Several software tools are required. I’m using Windows 10 in this article. Use the following links to download and install the software, if not already installed:

The versions I’m using are:

  • git version 2.30.0.windows.2
  • cmake version 3.22.5
  • gcc version 11.2.1 20220111 (GNU Toolchain for the Arm Architecture 11.2-2022.02 (arm-11.16))
  • GNU Make 4.3.90
  • Eclipse IDE 2022‑06, NXP MCUXpresso IDE 11.5.1
  • J-Link V7.66e

Make sure that git, make and cmake are available in your PATH or system environment.

In Eclipse, use the menu Help > Install new software and point to the following update site:

https://download.eclipse.org/embed-cdt/updates/v6/

From there, install the Embedded C/C++ GDB JTAG Debugging and Embedded C/C++ J-Link Debugging.

Raspberry Pi Pico SDK

First, the Pico SDK needs to be installed. For details see https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf which requires git installed.

Create a new empty directory: in the following sequence I create a new directory ‘pico’ in which I clone the SDK and the examples in a console:

mkdir Raspy\pico
cd Raspy\pico
git clone -b master https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk
git submodule update --init
cd ..
git clone -b master https://github.com/raspberrypi/pico-examples.git

Set the following environment variables, pointing to the Pico SDK and the toolchain to be used:

setx PICO_SDK_PATH "c:\Raspy\pico\pico-sdk"
setx PICO_TOOLCHAIN_PATH "C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\11.2 2022.02\bin"

After that, close the console and open a new one.

💡 Instead of using the setx command, one can use the System Control in Windows to set the environment variables (recommended).

To be able to import the examples into Eclipse, I have to convert them. Create a new folder on the same level as ‘pico-examples’ and convert the projects for Eclipse:

mkdir pico-examples-eclipse
cd pico-examples-eclipse
cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ../pico-examples

With this, we have everything in place. Next we are going to use Eclipse for building and debugging.

Import as Eclipse Project

The converted examples can be imported as ‘make file projects’ into Eclipse, using File > Import > C/C++ Existing Code as Makefile Project:

Alternatively, I can import the project with File > Import > General > Existing Projects into Workspace.

Now I have a normal make/cmake project I can use in Eclipse with ‘build’ or ‘clean’ commands:

Raspberry Pi Pico Project in Eclipse
Building in Eclipse CDT

Create a new Project

To create a new and fresh project, you can follow the steps below:

Create a new folder for the project:

mkdir myProject
cd myProject

In that folder, create a new file (main.c) with the following ‘blinky’ content:

#include "hardware/gpio.h"
#include "pico/stdlib.h"

#define LED_PIN   (25)

int main(void) {
    gpio_init(LED_PIN);
    gpio_set_dir(LED_PIN, GPIO_OUT);
    while (true) {
        gpio_put(LED_PIN, 1);
        sleep_ms(250);
        gpio_put(LED_PIN, 0);
        sleep_ms(250);
    }
    return 0;
}

Create a new file CMakeLists.txt, with following content:

cmake_minimum_required(VERSION 3.13)

include(pico_sdk_import.cmake)

project(test_project C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)

pico_sdk_init()

add_executable(myProject
  main.c
)

pico_add_extra_outputs(myProject)
target_link_libraries(myProject pico_stdlib)

Copy the file pico_sdk_import.cmake into the folder, from pico-sdk\external.

Within the ‘myProject’ folder, call cmake:

cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug .

Now the project is ready to be built with:

make

To use the project with Eclipse, import it with File > Import >General > Existing Project.

New project imported in Eclipse

Debug Configuration

To debug the project, create a normal Eclipse debug configuration for it (menu Run > Debug Configurations). If needed, check the following settings:

Use the project and the .elf output file:

Debug Configuration, Main Tab

Use the JLinkGDBServerCL with SWD and RP2040_M0_0 device and the gdb from the tool chain:

Startup settings can be the default:

Debugger Startup Settings

To be able to see the hardware peripheral registers, specify the path to the SVD file:

Path to SVD File

Debugging

With this, press ‘Debug’:

Hardware debugging with Eclipse

With the SVD file set, I can inspect the hardware peripherals with the debugger

Hardware Peripheral Information based SVD File Information

Summary

It is very simple and easy to use the RP2040 with Eclipse and cmake. The output binaries include the file for the the UF2 bootloader. But doing real developing needs real tools and debugging capabilities. The combination of Eclipse with the J-Link makes a perfect development environment for me: it is easy to use and the Eclipse hardware debugging capabilities are excellent. Compared to other IDEs and debugging solution, it is much closer to the hardware, and debugging FreeRTOS applications on the RP2040 is easy with the Eclipse plugins.

Happy pico’ing 🙂

Links

22 thoughts on “Getting Started: Raspberry Pi Pico RP2040 with Eclipse and J-Link

  1. Thanks for this Eric. I’d started to look at the Pico a little while ago, but had only got as far as the VSCode examples before I had to give up. This should be good for getting me a bit further on!

    Liked by 1 person

    • Yes, there are many examples with VSC out there, but it is by far not up to the overall experience with Eclipse, especially debugging. The VSC editor engine is great, but debugging and embedded features is by far behind. This might change over time, and Microsoft seems to make small steps into the right direction.

      Like

      • Looking back at the message I posted on the Pi Pico forum (https://forums.raspberrypi.com/viewtopic.php?t=329752) it looks like the cmake step may have been the missing link. CMake is one of those things I really should learn more about, but I haven’t had a genuine need to (yet) so, as I mentioned in that thread, it’s something I’ve used to create GNUMakefiles for FOSS packages I use, but not something I’ve had to make myself.

        Thanks again.

        Liked by 1 person

        • Yes, compared to make, CMake is very complex to start with. The important thing to remember about CMake is that it is just a ‘front-end’ to make/ninja/nmake/etc. So CMake basically is a generator for the builder used after that. And you have to run CMake initially to generate all the needed files. CMake has improved a lot over the recent years, and there are more and better documentation around it. I learned it the hard way with ESP32 projects migrating from make to cmake+ninja: if it works, then of course it is great: if there are issues, you have to deal with multiple tools and their settings. Definitely not an easy.

          Like

    • I used command line for the Pico – build and debugging – but if you want maximum frustration with VSCode and embedded development, trying playing with the Sony Spresense. Ugh! I got it working, but even after that, Sony’s “menu” system of setting parameters to use for chip functions is . (There’s no emoji, there; imagine there is.) There’s a level of masochism, there.

      Liked by 1 person

      • I have not looked into the Sony Spresense at all. I’m all for transparent tools with command line commands working in the background. a menu or GUI system is a cool thing to start with, but later you want to have the choice of development way. IMHO this is one part of why VSC is pretty good, as you can do all things behind it with cmd commands. It is just that it tends to make simple tasks very hidden and obscure, if you do not know where exactly it is. But I think this is true for any system at least at the beginning of a learning phase.

        Liked by 1 person

    • Yes, I fear the same, as for the WLSCP devices (https://mcuoneclipse.com/2022/07/14/are-wlcsp-the-solution-during-silicon-shortage/) happened recently. It might be less of an issue because the RP has no flash protection feature, making it less attractive for many products/companies. But I see lots of companies moving away from NXP, TI and STM to the RP one, because the other vendors have deeply disappointed them in the last years with their communication and delivery rules. Clearly, there are no guarantees for the RP supply, but at least they are available in quantities. What I observe as well are many small and medium companies are investing into independent RISC-V silicon: this is not only a thread to ARM Inc. (already impacted by that), but as well to the traditional MCU vendors.

      Like

      • I’ve noticed more noise, lately, about RISC-V: seeed Studio has a number of offerings. But the problem with seeed is that they push stuff out, and then abandon it – they’ve burned me – so I’m leery of buying their stuff.

        Liked by 1 person

        • Yes, I have the same feelings about Seeed on this. But this is exactly why I see ‘mid-size’ companies designing their own RISC-V device, tailored for their needs. It seems that for a few 10k$ you are able to get our own device manufactured. For sure this won’t play well if you just need a few MCUs. But having your own custom MCU, and have it available in your hand these days is a true competitive advantage to me.

          Liked by 1 person

  2. Very nice writeup! I love the Pico. My kid bought one for me for last Christmas, and I was like, “Huh. What is this thing? Well, he got it for me, I’ll play with it.” After I got it working – all command line, at that point, including arm-none-eabi-gdb – I changed my mind: This is a pretty cool chip, and how did I not know about this for a year?! I ended up buying 3 or 4 more, just because they’re so cheap – and dual cores! He got the Pimoroni Unicorn shield for me, as well, so since Christmas, it’s been running as a desktop clock, but I need to find something more useful for this chip. I’ll have to see how difficult it is to port these instructions to a Mac.

    Liked by 1 person

    • Yes, the P2040 is a really cool device. It does not have the most advanced peripherals compared to NXP or STM devices: but they are pretty straight-forward and I feel have less issues then the ‘over-engineered’ counter parts. I have not really tapped into the multi-core of the RP2040, but for sure I will sometimes in the near future.

      Liked by 1 person

      • Thank you for the post Erich. What about the reset line for the SWD program/debugging? This is required by jlink in M0+ devices. Here it seems not necessary as you use only 4-wire debug connections but I don’t know why.

        Liked by 1 person

        • The reset line is optional for SWD debugging. The SWD command set allows to reset a target. Of course if the target does not respond to this, a reset through the reset line is required. But it is not mandatory.

          Like

  3. Finally! I can use Eclipse with the Pico. I’ve been using MicroPython which is perfect for the Pico (no need for an RTOS). And it’s easy to run a thread in each of the cores. Now I need to create some C module libraries for MicroPython and this is the perfect solution. I especially like the ability to use Eclipse by itself without loading the NXP XPresso package. Thank you!

    Is it possible to import an Arduino sketch into Eclipse? I believe this is possible with Studio 7 (which is based on VSC).

    As mentioned in an earlier post, there is no flash security with Pico. However, you can use an external ATECC608 security device to validate your hardware and software (well, you used to before they become unavailable). The new Arduino Pico comes with it. Both Adafruit and Sparkfun offer ATECC608 Qwicc boards (out of stock, of course). This might be a good topic for a future article (hint, hint).

    Another suggestion is a plug-in for Eclipse that will automatically generate the required CMakeLists.txt file. Or perhaps a future article on CMake.
    Cheers…

    Liked by 2 people

  4. Thank for the wonderful articles. These are the foundations that every new programmer must understand before start using any IDE.Regarding component shortage one lesson I have learned is that single sourcing is very dangerous . I have a product running requiring some thousand kinetics parts every year . the last answer I got was ‘we are very sorry for the inconvenience but we can’t provide you the parts’. As for the Asian market you can find the chips I was buying 1usd for 150 usd on average .So my advise is think very well before you invest time money and effort learning new things to single source solutions..

    Liked by 2 people

    • A single source is always a problem for critical components. This includes hardware and software/tools. That’s why Eclipse is so popular, because there are so many vendors or distributions available, up to the point that you can create a DIY version because open source. VSC is popular too, but it is not fully open source (Microsoft keeps the most important parts closed). But at least in the IDE world there are many different options. As for the build tools, with GCC and commercial compilers you have choices too, same for debug (OpenOCD, J-Link, …). The most difficult part to change remains the MCU, but with a good software architecture this is not that hard as well. You just need to be prepared and having multiple choices at hand all the time.

      Like

  5. Hey Erich,

    Great minds think alike. I just got my rPico this weekend and pulled it out of the box on Saturday and started to play with it.

    Thank you for the Eclipse set up explanation – it really came through at the perfect time! Let’s hope they stay in stock, I also got a rPi 4 (2GB) to play around with as well.

    I hope you’re keeping well and keep your chin up!

    myke

    Liked by 1 person

    • I’m using the Pico for 6 months now, but only recently it got ‘real’ with several projects running with it. I really hope that the chip will continue to be available. So far it is doing far better than any of the ‘big’ silicon providers on that subject.

      Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.