Segger Embedded Studio cannot find include

[Georgi Valkov]

Using the nRF Connect SDK from Nordic Semiconductor is a terrible experience. One reason it being unreliable with many broken samples. And another being the Segger Embedded Studio, which takes ages to open a project, requires a reload every time a project is changed, forgets the project settings each time a new project is opened. Once we reach the point of building the project, many undefined symbol errors are reported during the linking phase. These can be resolved by adding correct CONFIG_ flags in the .prj file, yet this is is not obvious in any way, and finding the correct flags required by a project is a long and painful experience. Once we get past that point, and we try to program our application, Segger cannot find some headers. And it keeps asking again and again, I've had cases of more than 20-30 prompts. The whole process is extremely tedious and unproductive.

https://youtu.be/BOM5gGFlUQ8

[Georgi Valkov]

Quote from Segger support:

Sorry to say that, but these are not generic Embedded Studio issues, but seem to be related to how the project is set up.

Therefore, please understand that we can only provide limited support to this case.

However, the reason why Embedded Studio a) cannot find the include files and b) does not recognize that the output is up to date is most probably related to how the build system is set up.

To a) This may happen when the output is built with relative paths. Since Embedded Studio does not know to which a path is relative, it cannot resolve it. A fix would be to make the compiler/linker use absolute paths.

To b) This may happen when input files are updated during build and as such have a newer timestamp than the output.

Unfortunately, both cases are heavily related to the project.

Since the Nordic SDK uses an external toolchain we can not provide any guidance on where things could be configured.

We asked Nordic to provide better support to this case.

You might want to go back to their forums with the new information.

Best regards,

Johannes Lask

Product Manager

[Einar Thorsrud]

Hi,

There is a lot of things here, but I will try to comment what I can.

Using the nRF Connect SDK from Nordic Semiconductor is a terrible experience. One reason it being unreliable with many broken samples.

The nRF Connect SDK is a bit different then the nRF5 SDK, and many samples are part of Zephyr and not necessarily tested or integrated with nRF devices. Perhaps this is the problem here? 

forgets the project settings each time a new project is opened

Yes. To make configurations persistent, you would need to make the change in prj.conf (as you have noted). SES does not do this for you, unfortunately.

Once we reach the point of building the project, many undefined symbol errors are reported during the linking phase.

If you use a sample project that would indicate that there is a problem with the toolchain. Can you specify which sample you use, from which NCS version, and how you installed the toolchain? If you are on Windows, then using the Toolchain manager which is part of nRF Connect for Desktop is the easiest way to install a functional toolchain.

Lastly we have got some feedback that the nRF Connect SDK together with Segger Embedded Studio is not always very user friendly. We are noting the feedback and are looking into how to improve it in the future.

[Georgi Valkov]

Hello Einar!

Einar Thorsrud said:

The nRF Connect SDK is a bit different then the nRF5 SDK, and many samples are part of Zephyr and not necessarily tested or integrated with nRF devices. Perhaps this is the problem here? 

What difference does that make to your clients who buy a large amount of chips and are expected to write software on top of the broken SDK? When Nordic offers an SDK with its hardware it is expected to work correctly. The most important samples that are broken are: connectivity_bridge and GPS. They even come precompiled with the firmware. It is a common use case, where the developer simply programs a ready sample on one of the CPUs and then develops code for the other (nRF9160 + nRF52840).

https://devzone.nordicsemi.com/f/nordic-q-a/67372/connectivity_bridge-malfunctions-when-ble-client-disconnects-and-reconnects
https://devzone.nordicsemi.com/f/nordic-q-a/68716/gps-stops-updating-timestamp-after-a-few-days-of-uptime-indoors/282807#282807

Einar Thorsrud said:

Yes. To make configurations persistent, you would need to make the change in prj.conf (as you have noted). SES does not do this for you, unfortunately.

Do you expect every developer to know this and also know how to do it? Have you tried switching between multiple projects? Every additional task we have to repeat has a negative impact on the productivity. Your team might want to work with Segger and improve this.

Einar Thorsrud said:

Once we reach the point of building the project, many undefined symbol errors are reported during the linking phase.

If you use a sample project that would indicate that there is a problem with the toolchain. Can you specify which sample you use, from which NCS version, and how you installed the toolchain? If you are on Windows, then using the Toolchain manager which is part of nRF Connect for Desktop is the easiest way to install a functional toolchain.

Say we start from a copy of existing sample. Then add some posix calls or use some functions that are commonly used. We add the proper headers but the project fails to build because of missing symbols. The solution is to find that CONFIG_ flags needs to be defined in order for that symbol to become available. Of course we have no clue what config flags have to be added, and it's a long research and guess work. As a reference, on our own RTOS - EUROS, we just add the headers and everything just works. It's not a question on which particular samples or functions are used. Rather a matter of good and bad practices.

The toolchain is installed from the nRF Connect GUI on both Windows and macOS.

Einar Thorsrud said:

Lastly we have got some feedback that the nRF Connect SDK together with Segger Embedded Studio is not always very user friendly. We are noting the feedback and are looking into how to improve it in the future.

Alas the Nordic SDK is a very unproductive environment. Try using EUROS: https://www.euros-embedded.com/

Another example: I wanted to make a small change to the GPS sample, so that a copy of the NMEA strings is sent to the second UART. Usually this should require three lines: 1. open UART, 2. check if valid, 3. send. The Zephyr API forced me to write 300 lines of code to achieve this simple thing. When the complexity is increased 100 times, I'm not surprised that many samples are broken. After trying to fix the connectiviry_bridge for over a week, I figured that's unreasonable. Porting and entire RTOS + UART driver took two days. And it's rock solid.

[Einar Thorsrud]

Hi,

Thank you for the feedback. I understand what you are saying, and you definitely have some valid points. I would say though that the nRF Connect SDK is still quite young, and we are working hard to improve all aspects of it, including quality and user friendliness.