nRF Connect Install requires a huge amount of packages

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Wed, 22 Nov 2023 07:33:25 GMT

Hi Brian

Please open a new ticket if you have a question not directly related to an older case, the devzone is not really designed do handle long running cases with multiple different questions.

The short answer is that the nRF51 series is not officially supported in the new SDK, but many samples will still work by using the nrf51dk_nrf51422 board definition, including many of the Bluetooth samples.

In other words it should be possible to put together a lab session based on the nRF51 boards and the new SDK, if you find a set of features and libraries in the SDK that work fine on the older boards.

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

Brian — Wed, 22 Nov 2023 04:28:31 GMT

[quote userid="2116" url="~/f/nordic-q-a/93839/nrf-connect-install-requires-a-huge-amount-of-packages/396018"]Case in point, if I download the latest and greatest version of the nRF Connect SDK I can still build many of the Bluetooth samples for the nRF51, a device released 12 years ago![/quote]

Hi Torbjørn, I am a teacher and I have a bunch of nRF51822s that I want to use to set up a lab for my students to use. If I can get help using the latest nRF Connect SDK to build apps on the older chips, I would certainly make sure my students get an extra positive review of Nordic Semi. 😁

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Tue, 22 Nov 2022 09:14:15 GMT

[quote user="hnhoan"]It has been said time over by Nordic people that if you want to use the nRF53 or nRF91 you have use Zephyr!!! SDK not available otherwise. DUH !!![/quote]

Then I am glad I could clear up that misunderstanding 🙂

RE: nRF Connect Install requires a huge amount of packages

Nguyen Hoan Hoang — Tue, 22 Nov 2022 05:36:49 GMT

[quote userid="2116" url="~/f/nordic-q-a/93839/nrf-connect-install-requires-a-huge-amount-of-packages/396579"]Just to be clear, Nordic doesn't force you to do anything[/quote]

It has been said time over by Nordic people that if you want to use the nRF53 or nRF91 you have use Zephyr!!! SDK not available otherwise. DUH !!!

RE: nRF Connect Install requires a huge amount of packages

brianreinhold — Mon, 21 Nov 2022 11:42:50 GMT

The non-blocking restriction does make life more difficult but most non-OS based embedded systems run in that manner (at least that is what I am led to believe). In my project I have a situation where the characteristic value can be longer than the MTU. So it has to be sent fragmented. So when notifying, one would send 6 notifications but then one needs to wait for the ack event before one can send more. So I would exit the send routine and basically wait on sd_app_evt_wait() and handle the events myself when it woke.

I have never really fully understood that call, but I assumed it could only be called in one place in your program and your entire program ran around this call. When it would exit, you would check everything you might need to do and return to the sd_app_evt_wait(). Anything else, like a sleep, is just a busy loop and a horrible way to wait for something to happen before continuing,

So that's what I have done. When I used the pc-driver-btle library on the PC, I could use mutexes and semahores which DID dramatically simplify the program - but at the cost of having a multi-tasking OS which diminishes real time implementations.

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Mon, 21 Nov 2022 10:12:42 GMT

Hi Brian

[quote user="brianreinhold"]What I like about the SDK is SoftDevice. It is basic GATT/GAP and avoids the crazy BTLE profiles dreamt up by BT SIG. Having worked on a few of those standards, BT SIG just can't seem to learn simplicity and consistency and each profile is created without much thought to any other profile.[/quote]

You will be happy to hear that you get a standard GAP and GATT API, then. Running standard services is entirely optional 😉

Similar to the SoftDevice the API is grouped into groups such as GATT server, GATT client and GAP.

Because the Zephyr Bluetooth API is vendor agnostic it is much more focused on Bluetooth only, and follows the naming conventions set out by the Bluetooth specification.

The SoftDevice by comparison is more Nordic centric, and includes various features not technically Bluetooth related (such as the flash, clock, and power management functions).

[quote user="brianreinhold"]What I like about the nRF51 is that it can only do basic BTLE (4.2 maybe) and for those devices that need no more than that and are happy with the MTU of 23 that is good. Because it can only do 4.2 the memory footprint of the application is considerably smaller than the same application built using nRF52 devices. At least mine were. On the other hand if the nRF52 is now cheaper and takes less power running the same application then it would be hard to argue for starting a new project with the nRF51[/quote]

You won't be able to build Bluetooth 4.2 stacks anymore, but as I mentioned earlier you can link out functions that you don't need. Also, if you don't need more than 23 byte MTU the RAM consumption is lower.

As you say the nRF52 gives you more memory and performance for less cost, so there is really no good reason to use the nRF51 anymore.

[quote user="brianreinhold"]I do not know what nRFConnect brings to my application compared to the SoftDevice only BTLE version of the application. I did hear that the SoftDevice equivalent here will be source thus allowing optimization by removing unused functions which is not present in the SoftDevice library of the SDK.[/quote]

Ideally the Bluetooth part of the application should be relatively equivalent, the difference is more in the other libraries you have available as a part of the nRF Connect SDK.

You might find some value in being able to run your application on non Nordic hardware as well, even if we hope you will chose to stick to Nordic devices 😉

[quote user="brianreinhold"]I not sure how hard it will be using an RTOS. An OS is supposed to make life easier at the same time more of what goes on becomes a black box. There is something to be said for the simplicity of a non-OS application on an embedded system.[/quote]

Using an RTOS should ideally be no harder than using a bare metal system. A bare metal implementation is easier to understand intuitively, since there are much less layers of software between the hardware and your main function, but once you start writing more complex applications then you need to put more complexity into the application to handle things that an RTOS can otherwise do for you.

In a way having an RTOS moves some of the complexity from the application into the underlying RTOS, which makes it harder to learn the framework, but makes it easier to understand the various applications. This is especially useful when multiple people work together on a larger project, or when you have to work on many different projects rather than just maintaining a single one.

The main challenge of adopting to the RTOS way of thinking is that you have to structure your programs a bit differently. As an example, in the nRF5 SDK good coding practice was to never use blocking function calls. With an RTOS you are now free to use blocking calls from threads, since other threads will be able to run while one thread is blocked (and if all threads are inactive you will automatically go to sleep).

[quote user="brianreinhold"]Since I have no investment in any hardware yet (all my work has been for developing a generic standard for health devices) the only thing I loose by moving to nRFConnect is my time learning and implementing the new approach. For those who have units in the field the cost is probably much greater.[/quote]

Fair point. We don't really recommend people porting existing nRF5 projects to the nRF Connect SDK, unless they really need features not available in the older SDK. It is usually better to adopt the new SDK when you have a new project, making it easier to make a clean break.

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Mon, 21 Nov 2022 09:14:04 GMT

[quote user="hnhoan"]It is bad that a silicon vendor force the software people to lock in to a particular RTOS. [/quote]

Just to be clear, Nordic doesn't force you to do anything. Our devices use standard ARM Cortex M microcontrollers, and our datasheets document all the peripherals that are non standard (like the radio and the various interfaces). If you want to write all the software yourself, or use a third party software framework, that is entirely up to you.

The only limitation in using a third party software framework is that the support responsibility falls on the developer of the software, not Nordic. I don't think you will find any silicon vendor that takes support responsibility for other peoples software, unless they have an established partnership with the software provider in question.

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

brianreinhold — Fri, 18 Nov 2022 20:42:29 GMT

What I like about the SDK is SoftDevice. It is basic GATT/GAP and avoids the crazy BTLE profiles dreamt up by BT SIG. Having worked on a few of those standards, BT SIG just can't seem to learn simplicity and consistency and each profile is created without much thought to any other profile. Many profiles (especially in the health sector) just collect dust.

What I like about the nRF51 is that it can only do basic BTLE (4.2 maybe) and for those devices that need no more than that and are happy with the MTU of 23 that is good. Because it can only do 4.2 the memory footprint of the application is considerably smaller than the same application built using nRF52 devices. At least mine were. On the other hand if the nRF52 is now cheaper and takes less power running the same application then it would be hard to argue for starting a new project with the nRF51. The nRF52 DK was not cheaper than the nRF51 DK, but the nRF52840 dongle was cheaper than the nRF51 equivalent (if you can still find it).

I do not know what nRFConnect brings to my application compared to the SoftDevice only BTLE version of the application. I did hear that the SoftDevice equivalent here will be source thus allowing optimization by removing unused functions which is not present in the SoftDevice library of the SDK.

As an aside, Using SoftDevice only for BTLE makes porting to other MCUs easier - as all BTLE software (at minimum) has to handle these basic operations.

I not sure how hard it will be using an RTOS. An OS is supposed to make life easier at the same time more of what goes on becomes a black box. There is something to be said for the simplicity of a non-OS application on an embedded system.

Since I have no investment in any hardware yet (all my work has been for developing a generic standard for health devices) the only thing I loose by moving to nRFConnect is my time learning and implementing the new approach. For those who have units in the field the cost is probably much greater.

RE: nRF Connect Install requires a huge amount of packages

Nguyen Hoan Hoang — Fri, 18 Nov 2022 16:44:04 GMT

It is bad that a silicon vendor force the software people to lock in to a particular RTOS. In software, there are 1001 ways of doing the same thing. Software engineers like freedom of choices. People who have many projects developed over the years always have a library of code that are re-usable in new projects to save on dev costs and time. What you did is to tie their hand in the back to develop with nRFConnect and make all their previous investment go down the drain. The old SDK is easy integration into existing environment. It is actually easy to support the nRF53 the old ways. You just need to make a Softdevice alike running on the Net core and wrapper function over rpc communication. Exactly the same as you did with S132 for nRF52832 and S140 for nRF52840 with wrapper through SVC calls. Easy and fast to do. I don't get what you are doing with a Linux want to be (Zephyr) on a MCU. You should learn FreeRTOS way. Simple, no mess, no scripts, no Linux junk and it works with almost any MCU. Your old SDK too was like that. Just a compiler is needed. That is what needed for MCU.

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Fri, 18 Nov 2022 09:29:21 GMT

[quote user="hnhoan"]No, I didn't have time to investigate further for creating a ticket. I just wanted to know how to use the sdk_nrfxlib. It crashes on nRF52832 but works on nRF52840 so I used it instead.[/quote]

Please do report it if the problem persists. If it is a bug on our side we can then look to get it fixed.

[quote user="hnhoan"]I am not the only who doesn't like Zephyr obviously. About 2 years ago even one of your ex-support staff approached me with the same complains about Zephyr.[/quote]

Complaining is a big part of what we do in support, since we are among the first to play with new software and hardware releases 😉

There was certainly a lot more to complain about 2 years ago as well...

[quote user="hnhoan"]Did you know that you have lost a customer that could have used 10K-50K nRF91 per year due to Zephyr & nRFConnect SDK ?!! [/quote]

I am not aware of this particular customer, no, but after many years in Nordic I have seen my share of designs get lost for various reasons.

It's never a good feeling when it happens obviously, but you can't really do much about it except try to learn from your mistakes and move on.

As a final word I realize that I lack the rhetorical skills to win you over to my way of thinking. As a long time member of support I face issues and problems every day, and I try to apply a positive and constructive attitude to these issues rather than getting too focused on the negatives (which I succeed to do most of the time, if not all...). If not I think I would have tired of this job a long time ago. As a piece of friendly advice I would urge you to do the same, and obviously keep us in the loop on any issues you do find so we can do our best to help out 🙂

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

Nguyen Hoan Hoang — Thu, 17 Nov 2022 13:37:57 GMT

[quote userid="2116" url="~/f/nordic-q-a/93839/nrf-connect-install-requires-a-huge-amount-of-packages/396204"]Have you opened a ticket on the nRF52832 issue? [/quote]

No, I didn't have time to investigate further for creating a ticket. I just wanted to know how to use the sdk_nrfxlib. It crashes on nRF52832 but works on nRF52840 so I used it instead.

[quote userid="2116" url="~/f/nordic-q-a/93839/nrf-connect-install-requires-a-huge-amount-of-packages/396204"]Is this with the nRF52DK or a custom board/module?[/quote]

I don't recall but I believe both DK & custom board didn't work (using known working board with nRF5_SDK).

[quote userid="2116" url="~/f/nordic-q-a/93839/nrf-connect-install-requires-a-huge-amount-of-packages/396204"]I am sorry to hear you are having so much pain with the nRF Connect SDK. [/quote]

I am not the only who doesn't like Zephyr obviously. About 2 years ago even one of your ex-support staff approached me with the same complains about Zephyr.

Did you know that you have lost a customer that could have used 10K-50K nRF91 per year due to Zephyr & nRFConnect SDK ?!!

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Thu, 17 Nov 2022 12:43:34 GMT

I am sorry to hear you are having so much pain with the nRF Connect SDK.

Have you opened a ticket on the nRF52832 issue?
Is this with the nRF52DK or a custom board/module?
I can't say I have experienced this myself, normal BLE examples should work fine on the nRF52DK.

[quote user="hnhoan"]While with IOsonata same code works across nRF51, 52 5 years ago and you can use it with any RTOS you like. 53 in the works, [/quote]

Sounds like you have a good argument for providing your own solution then 🙂

There is definitely room for third party software frameworks for our devices, as long as people realize we can't support them directly since they are not developed by us.

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

Nguyen Hoan Hoang — Thu, 17 Nov 2022 02:45:43 GMT

Firstly why would anyone wants to use nRF51 on new platform. It is just a lame excuse. nRFConnect does not make life easier but big pain. Beside the examples don't work properly on nRF52832. Same examples work on nRF52840 only (not using coded phy of course). A simple UART BLE example does not work properly. After so many years you still unable to accomplished your goal. All of my customers complain about the new SDK is a big pain and they don't want it. While with IOsonata same code works across nRF51, 52 5 years ago and you can use it with any RTOS you like. 53 in the works,

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Wed, 16 Nov 2022 14:29:34 GMT

Making a big change like this is painful I know, but it is a change we would have to make at one point regardless. The nRF5 SDK was perfect back when we had a handful of single core devices, but got more and more complex to maintain as we added more and more devices with a wider and wider range of capabilities.

Case in point, if I download the latest and greatest version of the nRF Connect SDK I can still build many of the Bluetooth samples for the nRF51, a device released 12 years ago!

For the nRF5 SDK you have to go all the way back to version 12.3.0 to get support for the nRF51. The later versions support the nRF52 only.

(the nRF51 is not officially supported though in the nRF Connect SDK, but if you have some old kits laying around you can still use them)

Once you move your own platform over to the new architecture it should make life easier for you as well, in regards to supporting new nRF devices as they are released.

[quote user="hnhoan"]It would be a great help if the BLE stack is added to the nrfxlib. [/quote]

By this I assume you mean both the controller and the host?

There are no plans for this unfortunately since we are using the Zephyr host, rather than our own host implementation.

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

Nguyen Hoan Hoang — Tue, 15 Nov 2022 10:39:19 GMT

Correct, the nRF53 is not currently supported. That is because you forced people to use Zephyr.

Port is in the work using the sdk_nrfxlib with support for nRF53 in the IOsonata. App firmware on nrf52 can seamlessly compile for either old nRF5_SDK or nrfxlib. It would be a great help if the BLE stack is added to the nrfxlib.

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Tue, 15 Nov 2022 08:20:17 GMT

[quote user="hnhoan"]Wrong, it exists 5 years ago without any scripting software only gcc compiler. It has been posted on this forum since. [/quote]

Not for the nRF53 I assume 😉

Being multi core the nRF53 is more challenging to support with the same code base, which is something the nRF5 SDK wasn't really ideal for.

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Tue, 15 Nov 2022 08:01:24 GMT

Hi Brian

I got a tip that SES includes its own set of JLink drivers, so that probably explains why you never used the command line tools.

[quote user="brianreinhold"]When I was referring to project size I meant the size of the installed code on the MCU. Using SoftDevice for a BP meter was less than half the size of using the SDK BP example. For this project there is only one service and two characteristics, notifications/indications and client writes. No reads. It supports all health devices. That is another good reason for SoftDevice[/quote]

Peripheral only applications are usually smaller in memory footprint in the nRF Connect SDK (NCS), but not by as much as half.

Using the heart rate example as a reference again the nRF5 SDK version comes in at about 252kB flash, 43kB RAM, while the nRF Connect SDK version comes in at around 172kB flash 34kB RAM.

An advantage in NCS code size wise is that the Bluetooth host is implemented in source, which means you can optimize out procedures or functions that you don't use. With the SoftDevice you obviously didn't have this capability.

A drawback of NCS is that you need some libraries in place (such as the Zephyr RTOS) that you don't with the SoftDevice, but Zephyr is pretty light weight memory wise.

[quote user="brianreinhold"]I guess I will find out what nRFConnect SDK offers..[/quote]

The best of luck. If you have any issues along the way you know where to find us 🙂

Best regards
Torbjørn

RE: nRF Connect Install requires a huge amount of packages

Nguyen Hoan Hoang — Tue, 15 Nov 2022 06:53:30 GMT

And exactly the same main file can run fine on the nRF51, nRF52 or nRF53 devices by only changing the board file in the build, which is something the nRF5 SDK could only dream off...

Wrong, it exists 5 years ago without any scripting software only gcc compiler. It has been posted on this forum since.

https://embeddedsoftdev.blogspot.com/2017/12/bluetooth-le-with-nordic-nrf51-nrf52.html

https://embeddedsoftdev.blogspot.com/2018/02/bluetooth-le-with-nordic-nrf51-nrf52.html

With only a few line of code, no RTOS, no 10K line of defines.

Original source code here

https://github.com/I-SYST/EHAL

new version moved here

https://github.com/IOsonata/IOsonata

RE: nRF Connect Install requires a huge amount of packages

brianreinhold — Mon, 14 Nov 2022 21:27:18 GMT

Hi! Thanks for the reply. I do use nFR Connect for desk top mainly for installing hex files on the nRF52840 dongle, so I would not get rid of that.

If the command line tools are being used I am not actively using them. All building and installing of HEX files onto the DKs have been with Segger ES or Keil IDEs. For debugging I also use these IDEs and for display of log messages I use putty. Perhaps the command line tools could replace putty.

I used SoftDevice because it was right at the GATT/GAP level. The project I am working on is basically proprietary above that so there is little help from the BTLE part of the SDK. The SoftDevice APIs were straight forward enough that I found them easier to use than the SDK for the BT SIG health device profiles perhaps because I didn't have to learn as much. Every GATT BTLE project depends (in the end) upon those basic GATT features so there was little difference between writing a BP or a Glucose meter using SoftDevice. The crap that goes in the measurement characteristics is always a pain and I blame BT SIG for that. IN addition I started with the Btle PC driver package on the dongle which ONLY has SoftDevice.

When I was referring to project size I meant the size of the installed code on the MCU. Using SoftDevice for a BP meter was less than half the size of using the SDK BP example. For this project there is only one service and two characteristics, notifications/indications and client writes. No reads. It supports all health devices. That is another good reason for SoftDevice. I guess I will find out what nRFConnect SDK offers..

RE: nRF Connect Install requires a huge amount of packages

ovrebekk — Mon, 14 Nov 2022 16:19:12 GMT

Hi Brian

[quote user=""]However, I could not find the locations on my computer where they were installed. VS Code itself is installed on a second disk E.[/quote]

VSCode extensions should be installed in the %USERPROFILE%\.vscode\extensions folder. Typically something like c:\Users\USERNAME\.vscode\extensions. I confirmed this on my own machine, and can see 5 folders with the nordic-semiconductor prefix for the various Nordic extensions.

[quote user=""]I do not intend to use the command line tools and have never used this tool to date. Why do I need this? [/quote]

That is odd to hear you have never use this before, the nRF Command Line tools contains the base drivers to interface with the debug chip on the various nRF52 DK's, and is used for flashing and debugging the DK's. I would expect you to have used this when working with the nRF5 SDK and the SoftDevices.

These tools are listed in the Tools and downloads section of the nRF52 series DK's, based on the 'old' platform (nRF5 SDK and SoftDevice).

[quote user=""]Is it absolutely necessary to install all these third party packages like 'chocolately', 'west', python???[/quote]

Chocolatey should no longer be necessary. This is a packet manager that was used to install the various toolchain components in the first releases of the nRF Connect SDK, but has now been replaced by the Toolchain Manager (TCM) application in nRF Connect for Desktop.

When using the TCM it is basically a one click operation to install a specific version of the SDK, and this includes the various toolchain components such as West and Python.

You define the install directory for any new SDK versions. Then the SDK's will be installed in a subfolder named v2.1.0 for instance, while the toolchain will be installed in the /toolchain/v2.1.0 folder.

At the moment each SDK install comes with its own version of the toolchain which does contribute to the bloat definitely, but greatly reduces the chance of build errors caused by incorrect toolchain components.

[quote user=""]Do I really need all this? Why Python? That's a whole SDK for building Python applications ... that is huge.[/quote]

Python is used by a lot of the build scripts in the toolchain and as such is critical, with West being the most important of these Python scripts. West is the meta tool that handles the download and update of the various repositories included under the nRF Connect SDK umbrella, and can also be used to start build, flash and other operations from the command line.

I doubt the whole Python SDK should be downloaded though. The entire toolchain comes in at about 1GB, and I think the Python binaries are a relatively small portion of this.

[quote user=""]How many of these can I get rid of once nRF Connect is installed. What does 'chocolatey and west do? I realize that I can install even more stuff and get the manager to do all of this for me but that is just hiding all the junk getting downloaded and installed.[/quote]

I doubt there is much you can get rid of since most of these tools are used for building applications. Possibly you could get rid of chocolatey and leave the scripts in place, but I am not sure.

Frankly you will be much better of using the Toolchain Manager. As I mentioned earlier all the resulting junk can be found in the [SDK_FOLDER]/toolchain/v2.x.x folder, so using the TCM should not make it any harder to find compared to chocolatey 😉

You can uninstall the TCM and nRF Connect for Desktop once everything is installed, these are not used for building or developing applications. That said there are a lot of useful apps within nRF Connect for Desktop, such as the Bluetooth application and the Power Profiler (for owners of a Power Profiler Kit), so I think this is an application worth keeping.

If you really want to keep your system as un-affected as possible the best option is probably to install everything in a virtual machine. If you want to go down this route though it is recommended to run a virtual Linux installation, since the build performance is generally faster in Linux than on Windows.

[quote user=""]I went to the Nordic 'Seminar' in Boston (Waltham) about a month ago where I was introduced to nRF Connect.[/quote]

I remember, I was there!

I think we had a chat at the end, regarding the work you have been doing with the SoftDevice 🙂

I didn't represent nRF Connect though, so any promises made about it I will put on Karl's shoulders 😜

[quote user=""]So the actual goal here was to see if this project would have a smaller footprint using SoftDevice (used now) or the nRF Connect SDK and which was easier to implement. There is interest in this project (which is a generic health device model over a BTLE tunnel) primarily in China at the moment so It would be nice to have an answer. One thing the seminar did not reveal was the massive amount of support software needed to get off the ground.[/quote]

Are you talking about memory footprint on the device, or the size of the toolchain?

What is more easy to implement is a complicated question to answer. The toolchain and build system is definitely more complicated, but making applications is typically not because of the advantages the build system offers. As an example the Bluetooth heart rate example in Zephyr is about 130 lines of code i main.c, compared to a much more complex example in the nRF5 SDK. And exactly the same main file can run fine on the nRF51, nRF52 or nRF53 devices by only changing the board file in the build, which is something the nRF5 SDK could only dream off...

Your development model is a bit different than most customers though, as you don't really use any of the libraries in the SDK and just program for the SoftDevice directly. I am not sure this will work as well in the new SDK, since we don't really have a SoftDevice anymore, but have split the BLE controller and host into two separate pieces of software.

[quote user=""]One thing the seminar did not reveal was the massive amount of support software needed to get off the ground.[/quote]

To be fair, I think we mentioned most of these tools in the seminar, but it is true that Python isn't mentioned in the slides. This I can take as feedback to future iterations of the slides. Chocolatey is not mentioned either, but as I said we recommend using the TCM instead, rather than having to install all the tools manually.

Finally I hope you have taken the time to go through the DevAcademy?
It really makes a big difference in getting started with the nRF Connect SDK 🙂

Best regards
Torbjørn