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

[Charlie]

Hi Damien,

I’m writing to ensure you are fully informed about the implications of continuing to use nRF9160 with NCS v1.6.1. Let me outline the key reasons why updating to the latest NCS and MFW versions is strongly recommended:

1. NCS v1.6.1 was released over three years ago (June 29, 2021). Since then, critical tools such as the nRF Connect for VS Code extensions (introduced in October 2021) and various dependency libraries have evolved. This can create challenges when setting up and maintaining NCS v1.6.1 in today’s development environment.

2. Over the past three years, numerous bug fixes and enhancements have been made to both NCS and MFW, significantly improving stability and performance. Staying on an older version might lead to issues that eventually necessitate an update. You can find detailed changes in their respective release notes on the product pages.

3. Supporting legacy setups like NCS v1.6.1 can be time-consuming and may result in delayed responses. Setting up and troubleshooting such an outdated environment can also be a challenge, even for experienced users.

4. While the UDP sample code itself hasn’t changed much (basic socket functions like socket, connect, and send remain the same), upgrading provides access to improved stability in cellular IoT connections, benefiting your overall development process.

I encourage you to communicate these challenges and the advantages of updating with your stakeholders to make an informed decision. If you still wish to remain on NCS v1.6.1, please be aware that support responses might take longer due to the complexities involved.

Let me know your decision, and I’ll assist accordingly.

Best regards,
Charlie

[DamoL]

Hi Charlie, 

As already outlined, we know we shouldn't be on such an early version, but at this point it means completely rewriting firmware for a product that is out in it's thousands across the world. We have found multiple bugs in 1.6.1 and I have fixed them manually. 

I am also not sure how we are meant to keep up with the SDK releases. When 1.7.0 was released, I could not find a simple way to port code I had written in 1.6.1, as simple things like project configuration names had been changed, and libraries for things we used just disappeared. That was one release apart, and you seemingly release a new SDK every 8-10 weeks so I honestly don't know how we are meant to stay up to date.

However we are where we are, and we don't have much chance of our new guy being able to help remake our firmware on an updated SDK without him able to build the current one and understand how it works, so if you could please assist us with getting an environment set up, that would be great. 

Damien