Setting up the development environment for older SDKs in 2024

[DamoL]

Hi, 

We have recently acquired a new firmware engineer, and would like to get him set up with a development environment for developing code for our product. The problem is, we were early adopters of the nRF9160, and we are still using SDK 1.6.1. Now I know whenever I ask a question about something I often get the response that I need to update the SDK version - but we have had nightmares trying to do that. Our new engineer was going to be tasked with giving that a go, but it would certainly help if he could get the current environment set up on his machine. 

He has tried getting it setup, and I have had a go on another computer. Both computers were on Windows 11, so we presumed there maybe a problem with that. We set up a virtual machine with Windows 10 on his machine, and again, we ran into the same problem. It seems it cannot include the prj.conf file in the build. We always get  - Kconfig Errno 22

Something is definitely not right in the setup of the SDK. We have tried it multiple ways

1. nRF Connect for Desktop - Toolchain Manager - download and install v1.6.1 - open VS Code - make new project from sample

2. Download SDK from VS Code nRF Connect Extension - 1.6.1 - make new project from sample

3. Copy the SDK from the folder on my computer, put on new machine - make new project from sample

We both have the same version of the nRF Extension and VS Code. 

In every scenario, we get the same error in the problems tab on VS Code. If we manually build with a west command we can get it building, but it still seems to ignore some/all of the project configuration file. In the last attempt, we found that it built fine, did not show any errors on the terminal (still there on problems tab), but when it came to debugging, we could tell the config options had not been used. 

I know this stuff is very complicated in the background so I don't expect you to be able to debug this from what I have said, however, what would be good, is if someone could verify that if they use a clean PC, they can download and install SDK v1.6.1 and build a sample application - we keep using the UDP sample, as our code started with that.

Thanks in advance. 

Damien

[drollinger]

Hey, for what it is worth I kept a recipe of our builds. I recognize the pain in the toolchains and their short lived lives. I have the applications installations as well if you can not get ahold of them, let me know. Good luck

Nordic Semiconductor Toolchain Setup

Helpful Nordic tutorial: devzone

Windows command line toolchain with GCC and Make

Installers:  \\MISSOURI\SharedDocs\applications\NordicToolChain

	For this example, the Nordic Semiconductor tools were obtained off the downloads tab of the main page for the nRF52840 board, located at “https://www.nordicsemi.com/eng/Products/nRF52840”

1.	Install appropriate SDK from Nordic Semiconductors – Current version released week 27 of 2017 (first week of July) is nRF5 SDK v13.1.0, this version is necessary to use the S140 V5.0.0-2.alpha soft device which is the first “soft device” available with Bluetooth 5 support.
a.	Download zip file from Nordic Semiconductors website
b.	Extract to SDK folder – Currently using C:\Nordic
i.	Maybe split into versions in case it is desirable to have multiple versions of the SDK installed in the future?

2.	Install Nordic Semi command line tools via install executable (version used was, “nRF5x-Command-Line-Tools_9_6_0_Installer.exe”)
a.	Make sure location of embedded tools—which was “C:\Program Files\Nordic Semiconductor\nrf5x\bin\” for this computer—is added to the Path variable

3.	Install GNU Arm Embedded Toolchain (Standard version of GCC does not include support for embedded processors), this can currently be found at “https://launchpad.net/gcc-arm-embedded”
a.	 Make sure the system or user path variable is updated with the location of the \bin folder of the GNU ARM embedded toolchain, for this install this was “C:\Program Files\GNU Tools ARM Embedded\5.4 2016q3\bin”
b.	Update Makefile.windows found in “<nRF52_SDK_INSTALL>\components\toolchain\gcc” with path and version of GNU ARM embedded toolchain

4.	Install GNU Make if it is not already installed

5.	To program and run a project that does not require a soft device
a.	Compile an example in the SDK by opening a terminal, navigating to “<SDK>/examples/peripheral/<example name>/<board name>/blank/armgcc/” and entering “make” without quotes. Board name used currently is pca10056.
 
b.	Use the nrfjprog command line tool to program the compiled project onto the target board. This should be run from within the same folder that “make” was run from in the previous step. Note: replace nRF52 in all the following commands with the family of your target device, and change the name of the hex file in step b to the hex file output from running make in step 5. For this example, the target board was the nRF52840 development kit board, which is part of the nRF52 family. Note, if commonly only using one family of device, a default value can be set in the nrfjprog.ini file, which will prevent it from being necessary to type “—family nRF5x” for every command. This file resides in the directory where the command line tools were installed, which is “C:\Program Files\Nordic Semiconductor\nrf5x\bin” on this (32-bit) machine.

i.	Erase target:\> nrfjprog --family nRF52 –e
ii.	Program target:\> nrfjprog --family nRF52 --program   _build\nrf52840_xxaa.hex
iii.	Reset target and run application:\> nrfjprog --family nRF52 –r

6.	To program and run a project that does require a soft device (Which is any of the BLE projects)
a.	Compile and program the soft device onto the target
i.	Erase target as in step 5.b
ii.	Run “make flash_softdevice” in the armgcc folder referenced above, this will compile the soft device, erase the target, and load the soft device onto the target.
b.	Compile and program the progect
i.	Run make, as in step 5. 
ii.	Use the nrfjprog tool as in step six, omitting the erase step
1.	Program target:\> nrfjprog --family nRF52 --program _build\nrf52840_xxaa.hex
2.	Reset target and run application:\> nrfjprog --family nRF52 –r
c.	Alternative method that was discovered after viewing the makefile
i.	Build project:\> make
ii.	Erase target:\> make erase
iii.	program softdevice:\> make flash_softdevice
iv.	Program and reset target and run application:\> make flash

7.	The application should now be running on the target device


Here is my setup document. A couple notes:
•	The nrf52832 is pca10040 not pca10056 (which is the nrf52840), so everywhere this says 56 replace with 40 for programming the puck
•	The more recent version of the arm embedded gcc compiler may not work, version 4.9 does for sure
o	I put installers for the version of gnu make and arm gcc that I am using in Shareddocs\applications as we discussed
•	The note about nordic sdk versions is old, my system is setup up like C:\Nordic\<sdk version>
•	 I am not sure if the nrfjprog needed python. I don't think so, but it should give a helpful error if it does. If you do need to install python, install the latest version of python 2 (should be 2.7.something), python 3 does not work with the applications for the dfu stuff that we will probably be working with later
Another note. By reading the makefiles I discovered that Nordic added shortcuts so you don't have to type out all of the nrfjprog commands, and I have been using the makefile shortcuts mostly.

How I program the puck now:
•	Peripheral application
o	Navigate to <example directory>\pca10040\blank\armgcc
o	Run "make"
o	Run "make erase"
o	Run "make flash"
•	Bluetooth application
o	Navigate to <example directory>\pca10040\s132\armgcc
▪	Run "make"
▪	Run "make erase"
▪	Run "make flash_softdevice"
▪	Run "make flash"

[DamoL]

Thanks, I appreciate it. 

I have manged to get to a point where I can build within VS Code, it just doesn't pick up errors (valid errors I should say), so it is a bit tricky to work with. Unfortunately VS Code has to be internet connected for some of it features to work, and it auto updates itself and it's extensions, despite explicitly telling it not to. The debugging feature is sort of working, so I can just about get by. I would kill for an eclipse based IDE at this point though. We still have firmware written on a compiler and IDE version built in 2003 that we can easily build and debug code, so never thought we would have this issue with VS Code. 

Thanks,

Damien