GCC + Vscode build nRF52xxx development environment

Use GCC + Vscode to build nRF52xxx development environment under Windows... by Jinchen

Foreword

Recently, I encountered project requirements that required the use of Nordic’s nRF52xxx chip. I still remember the nRF52832 study notes I wrote when I first started writing blog posts. Now I see that there is no logic in the notes at that time, and I can’t quite understand them. Since Now that we are about to officially start using it, let’s take some notes again.

At the beginning, of course, you need to set up a good development environment, because you are already used to using the gcc environment, so this article will talk about how to use GCC + Vscode to build the nRF52xxx development environment.

I am Jinchen, and I have the same name on the whole network. I try my best to write each series of articles carefully, without being exaggerated or compromising. For those of us who take learning knowledge seriously, I am Jinchen, and the gold and stone are open!

1. Install ARMGCC and VScode

Because nRF52xxx is an ARM chip, in fact, I have a detailed blog post on using GCC and VScode to build an ARM development environment under Windows, which you can refer to directly:

Use VScode to build an ARM development environment under window – detailed version

Finally, you only need to ensure that the environment variables are configured. If you can find the arm-none-eabi-gcc version, it means that the configuration is complete:

For detailed steps, just refer to the above blog post.

2. Download nRF5 SDK

nRF5 SDK is the development kit for Nordic nRF5 series products. It includes the code we need for development. We can download it from
Download this SDK from Nordic official website, the download link is as follows: nRF5 SDK download

For example, we choose the latest version 17.1.0,

Scroll to the bottom and you will see the following image:

In the picture above, I found that although I have only selected the SDK_17.10 version, when you go to the bottom, the system will automatically recommend you so many compressed packages similar to s112. We will explain this in detail later. We can select the last item to download. , after downloading, we put it where we need it and unzip it, as shown below:

2.1 nRF5 SDK and softdevice

Let’s answer the above question. Why does the nRF5 SDK selected automatically recommend so many compressed packages? Those s112_nrf52_7.2.0.zip are Softdevice, which is the name of the Nordic Bluetooth protocol stack.

To develop the Nordic Bluetooth chip, we need to know that Nordic’s user program and protocol stack are separate, and they also need to be burned separately during burning. This is the difference from many other MCUs.

Moreover, the protocol stack provided by Nordic is provided to developers in the form of hex, as follows:

In fact, for the nRF5 SDK we downloaded, it already contains all the softdevices supported by this version, which exist in the \components\softdevice folder after decompressing our SDK, as follows picture:

Since it includes the protocol stack, why does the official recommend it to us?

That’s because the protocol stack will sometimes be updated to fix some bugs. Nordic will release the bug-fixed protocol stack in a higher version. The official will explain the specific repair details.

Note here that when you update the protocol stack, you need to pay attention to the name. If you have used a certain version of the protocol stack before and you need to update a new version of the protocol stack, you need to pay attention to downloading only the last digit that has changed. For example, use 7.2.0, and later the official release of 7.2.1, we can download it directly and overwrite the previous one. If the previous value changes, then the two versions of the protocol stack are incompatible and other processing is required.

2.2 Naming of Softdevice

Since we are talking about Softdevice, although it has nothing to do with building the environment, let’s have a brief understanding of it.

The following content is from the FAE of Nordic China:

Softdevice naming rule one:
Softdevice includes two underlying protocol stacks: BLE and ANT. BLE includes two roles: central (also known as master) and peripheral (also known as slave). For this reason, these different types of protocol stacks need to be named to distinguish them. The protocol stack naming format is Sxyz, where

x – indicates the type of protocol stack, 1 indicates BLE protocol stack, 2 indicates ANT protocol stack, and 3 indicates that it supports both BLE and ANT.
y – indicates the BLE role, 1 indicates the slave device, 2 indicates the master device, and 3 indicates that both the master device and the slave device are supported.
z – indicates the chip type, 0 indicates nRF51 series, 2 indicates nRF52 series
For example, S110 means that it only supports the nRF51 BLE protocol stack in slave mode.
For example, S130 represents the nRF51 BLE protocol stack that supports both slave mode and master mode.
For example, S132 represents the nRF52 BLE protocol stack that supports both slave mode and master mode.
For example, S212 means nRF52 ANT protocol stack
For example, S332 means that nRF52 supports both BLE protocol stack and ANT protocol stack, and the BLE protocol stack supports both slave device mode and master device mode.
Softdevice naming rule two:
Generally the same as naming rule 1, but the last two digits of the protocol stack number are the same as the chip model, such as S140, which means that this protocol stack is specifically used for nRF52840. Since the 52840 Flash has a large space, there is no need to create various subdivided protocol stacks. The S140 protocol stack is a large and comprehensive protocol stack that includes all Bluetooth functions.

3. Compile

Back to the topic, we have downloaded the SDK earlier, and we will continue to modify the configuration before it can be compiled normally.

3.1 Modify the Makefile configuration file

We need to modify the configuration of the Makefile in the SDK before compiling. You can see the configuration file in the path you decompressed \\ RF5_SDK_17.1.0_ddde560\components\toolchain\gcc. In windows and The files modified under the posix thread operating system are different, as shown below:

This test uses a windows system, so I modified the file as follows (there is an error in the picture below):

There is a slash missing after bin above ==! , don’t ignore the slash after bin.

3.2 Compilation

Then open the SDK through VScode, as shown below, just open it directly in the root directory of the SDK:

Then turn on interrupts in VScode and enter the example directory. What we enter below is the blinky example:

So modify Makefile.windows:

Make again, the compilation is successful, and the bin file and hex file are generated:

4. Burn

In fact, with the hex file, if we use J-Link, we can burn directly through J-Flash:

But this is also a bit troublesome. We still remember that when developing STM32, we would define some .PHONY pseudo-instructions in the Makefile for burning, as shown below:

Let’s see if the Makefile in the nRF5 SDK environment has similar instructions. In the last part of the Makefile, we can see the relevant instructions:

We tried to take a look, but of course it didn’t work:

We can see that nrfjprog -f nrf52 --program $(OUTPUT_DIRECTORY)/nrf52832_xxaa.hex --sectorerase is obviously a command of a certain software, so we must still be missing this burning tool.

4.1 Download nRF Command Line Tools

The missing tool above is called nRF Command Line Tools. The official download address is: nRF Command Line Tools download address.

Install directly after downloading. The tool comes with SEGGER J-Link software during the installation process. Because it is developed for ARM, if there is SEGGER J-Link on your computer, you can choose it. No installation, but many people suggest that it is best to follow the steps to install it all.

For the purpose of testing here, I did not choose to install SEGGER J-Link. Remember, it is best to unplug the device when installing!

The tool installation is complete. I was originally thinking about adding environment variables. In fact, it was added automatically during installation. Finally, the installation is completed. Based on our previous experience with some tools, we can simply take a look through the cmd command:

In this way we can use the nrfjprog command. Let’s return to the project. Pay attention here! After the tool is installed, Vscode must be restarted before it can be burned normally. We directly enter make flash and you can see that it can be burned normally:

We can test it again. Other pseudo-instructions, burning the protocol stack, and clearing the chip are all possible, as follows:

4.2 sdk_config

nRF5 SDK has a very important configuration file: sdk_config.h. The entire chip software architecture can be configured through the sdk_config.h file. We can see this instruction at the end of the makefile, indicating that we can also Use the make sdk_config command, as shown below:

If you cannot open the graphical configuration interface as shown above, it is because you lack the Java runtime environment. CMSIS Configuration Wizard is a Java application.

How to use the specific files will be discussed later.

Conclusion

At this point, we can compile and burn the nRF5 SDK examples, although it seems that my test board subprogram is not running ==!

We still don’t know a lot about it. What we need to do next is to understand the project structure of the SDK, know how to create a new project, and know how to debug, step by step.

Okay, that’s it for this article, thank you all!