This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Connect SDK v1.3.0 problems with SEGGER Embedded Studio

Here are some of the issues which I am facing in SEGGER Embedded Studio since I updated to nRF Connect SDK v1.3.0:

  • After I press Debug, Go, a dialogue box opens asking for some header. The header is usually different for different projects. Every time I open a different project and start debugging, the dialogue will appear.
  • Every time I open a project, the project options I had previously configured are lost. For Example: Project, Options, Debugger, Run to control = Never will be set to back to Always the next time I open the same project.
  • Opening projects and samples on macOS does not work. The message "experimental support" implies that it mostly works, which is incorrect. The proper term is: it never works. And there is no point in releasing useless software.

Parents
  • After I press Debug, Go, a dialogue box opens asking for some header. The header is usually different for different projects. Every time I open a different project and start debugging, the dialogue will appear.

    Could you try the solution suggested here: https://devzone.nordicsemi.com/f/nordic-q-a/35344/debugging-openthread-examples-with-segger

    Every time I open a project, the project options I had previously configured are lost. For Example: Project, Options, Debugger, Run to control = Never will be set to back to Always the next time I open the same project.

     How did you add the configurations? If you add it through ninja menuconfig or SES,

    then it will get saved in the .config file in the build folder (e.g. serial_lte_modem\build_nrf9160dk_nrf9160ns\zephyr\.config) and when you re-open the project, the .config file will get re-generated based on the configurations from the prj.conf and other Kconfig files. To make the changes permanent, you should add it to the prj.conf file.

    Opening projects and samples on macOS does not work. The message "experimental support" implies that it mostly works, which is incorrect. The proper term is: it never works. And there is no point in releasing useless software.

     Are you using the SES version that comes with the Toolchain Manager? Click Open IDE to use it:

    Or do you use an external version of SES?

    If you do use the Toolchain Manager version of SES and still get that error, I'll get someone else with a MacBook to recreate your problem and try to get to the bottom of it.

    Best regards,

    Simon

Reply
  • After I press Debug, Go, a dialogue box opens asking for some header. The header is usually different for different projects. Every time I open a different project and start debugging, the dialogue will appear.

    Could you try the solution suggested here: https://devzone.nordicsemi.com/f/nordic-q-a/35344/debugging-openthread-examples-with-segger

    Every time I open a project, the project options I had previously configured are lost. For Example: Project, Options, Debugger, Run to control = Never will be set to back to Always the next time I open the same project.

     How did you add the configurations? If you add it through ninja menuconfig or SES,

    then it will get saved in the .config file in the build folder (e.g. serial_lte_modem\build_nrf9160dk_nrf9160ns\zephyr\.config) and when you re-open the project, the .config file will get re-generated based on the configurations from the prj.conf and other Kconfig files. To make the changes permanent, you should add it to the prj.conf file.

    Opening projects and samples on macOS does not work. The message "experimental support" implies that it mostly works, which is incorrect. The proper term is: it never works. And there is no point in releasing useless software.

     Are you using the SES version that comes with the Toolchain Manager? Click Open IDE to use it:

    Or do you use an external version of SES?

    If you do use the Toolchain Manager version of SES and still get that error, I'll get someone else with a MacBook to recreate your problem and try to get to the bottom of it.

    Best regards,

    Simon

Children
  • Hi Simon!

    Unfortunately I cannot test your suggestions at this time, because my installation of nRF Connect SDK 1.3.0 stopped working on my Windows PC. I spoke with my colleague and he said that this had happened to him too. I was making some tests with the at_client, then I switched to serial_lte_modem. Initially it worked. But the sample running on Thingy:91 didn't replay to AT commands over BLE. So I started experimenting with prj.conf, and at some point I got an error that the project cannot be open. Then I restored the original version of prj.conf, and I'm still getting errors. I tried to move back to the at_client sample, which is at factory state, and now I'm getting errors with it as well. So at this point I cannot open absolutely any projects, and the SDK is unusable.

    I have a very important advice to Nordic Semiconductors: I understand that you are a hardware company and your hardware and documentation are truly fascinating. I met really kind, experienced and caring people on the phone. But in our modern world your hardware requires a reliable SDK to make it work. And sadly that SDK is in a terrible state. Officially there is a release for macOS, in practice it cannot open any projects. That's not experimental. Experimental implies there might be some minor issues, but it should work. The actual state on macOS is broken, since it doesn't work. I would call the Windows support experimental, because usually it works, but sometimes it fails completely or there are a lot of problems that need to be resolved. So please, take your SDK and software seriously! Ever since I started working on my project the SDK has been a no go barrier preventing me from making any progress.

    Also check line 166 in /opt/nordic/ncs/v1.3.0/nrf/lib/date_time/date_time.c

    it is causing build errors in some of our projects:

    K_SECONDS(CONFIG_DATE_TIME_NTP_QUERY_TIME_SECONDS),

  • Edit: these errors were caused because for some reason the board name had changed to secure instead of non-secure. I am certain I did not make this change. I wonder why experimenting with prj.conf would cause this?

  • Hi Simon!

    Regarding the dialogue to open a header file while a debug session starts, I believe that the offered solution is a workaround to hide the issue, and does not actually resolve anything. I would rather not do this, because there might be unwanted side effects.

    Regarding the project configuration. The logical thing to do is: highlight the solution, then click Project, Options… I even showed you a screenshot of that dialogue, in order to clear any doubts what I am doing. I find it illogical and bad design to have users go through any alternative path when changing project options. What I am doing should just work. Let me remind you that a software should be designed in a way to make it easy to use properly and hard to get unexpected results. Reality shows your team has made it the other way. It's just plain wrong!

    Regarding macOS, I installed nRF Connect from the official web page, then I installed and opened the Toolchain Manager, install nRF Connect SDK v1.3.0, Open IDE. Then I cannot open any projects. I have no clue about any other mysterious ways of installing and using the SDK. No one should care about them anyway!

  • Georgi Valkov said:
    Regarding the dialogue to open a header file while a debug session starts, I believe that the offered solution is a workaround to hide the issue, and does not actually resolve anything. I would rather not do this, because there might be unwanted side effects.

    Check out the answer given by Vidar in this thread. According to that answer, there won't be any unwanted side effects by ignoring the warnings.

    Georgi Valkov said:
    Regarding the project configuration. The logical thing to do is: highlight the solution, then click Project, Options… I even showed you a screenshot of that dialogue, in order to clear any doubts what I am doing. I find it illogical and bad design to have users go through any alternative path when changing project options. What I am doing should just work. Let me remind you that a software should be designed in a way to make it easy to use properly and hard to get unexpected results. Reality shows your team has made it the other way. It's just plain wrong!

    I absolutely see your point, and the current approach of adding configurations may be cumbersome, as you have to add it to the prj.conf to permanently change it. You also have to re-open the project (set the nRF Connect Options) for the changes in prj.conf to take effect. There are internal discussions about it and I just asked if there is any progress on this. I will keep you updated.

    I personally like to use the west tool to build and flash my projects (and Visual Studio Code for searching around and modifying the code). After you've built it for the first time (with the board specified), you can simply run west flash/west build, and it will automatically check if there are any changes to prj.conf/overlay files/.c files or any other files that affect the project and rebuild the project automatically if necessary.

    To use west, open either cmd or Git Bash in the Toolchain Manager. Click on "Open bash" to use Git Bash and click on "Open command prompt" to open cmd: 

    You could check out the NCS tutorial series, which will give you an introduction to the basic concepts in NCS and how to build some simple projects. Including how to use the west tool.

    Be aware that it is written using NCS v1.2.0, and you may encounter some errors if trying to follow it using NCS v1.3.0. I will update it soon to be compatible with NCS v1.3.0

    Georgi Valkov said:
    Regarding macOS, I installed nRF Connect from the official web page, then I installed and opened the Toolchain Manager, install nRF Connect SDK v1.3.0, Open IDE. Then I cannot open any projects. I have no clue about any other mysterious ways of installing and using the SDK. No one should care about them anyway!

    I will get ahold of a MacBook today and try to build some different nRF91-specific samples and see if I encounter any issues.

    Best regards,

    Simon

  • I got a hold of a MacBook today and tested some different samples, and I encountered difficulties and errors like you. The macOS support for the Toolchain Manager is still experimental and it may be a better option to install NCS using the Getting Started Assistant app or Manually. Hopefully, we can get the Toolchain Manager fully supported on macOS soon. 

    Earlier you said that you encountered some issues with Windows and the Toolchain Manager, could you be more specific on what is happening, and how to reproduce it? Then I can report it internally and we can improve/fix it.

    Best regards,

    Simon

Related