Hi,
I just wanted to note a few things that I found out during the usage of nRF Connect SDK v2.8.0 and its corresponding toolchain.
1. When I create a custom board with the VSCode extension wizard, the produced .dts file is not identified from the devicetree visual editor that expects the name of the file to end with _<soc> identifier. For example if the custom board name is set to "myBoard" and the nRF52840 is used , the devicetree visual editor expects the name to be like this: myBoard_nrf52840. So when re-create the sustom board from the beginning and the name now is "myBoard_nrf52840", the devicetree visual editor tries to find a dts file with the following name : myBoard_nrf52840_nrf52840.dts (!!!!). After trying it repeatedly the same thing occured.
Temporary solution to this (Thank you Vidar Berg ): Rename the created files by the wizard by adding the soc identifier at the end MANUALLY. For instance where you see "myBoard" rename it to "myBoard_nrf52840". Then enter the "myBoard_nrf52840.dts" and also change the #include "myboard-pinctrl.dtsi" to "myBoard_nrf52840.dtsi"
After performing this change the deviceTree visual editor will be able to see your board .dts file.
But even then you get a warning message from the .dts file saying ": "You are using Partition Manager to define the partitions. Devicetree definitions are ignored for this build." so then you need to put "CONFIG_PM=n" (in theory) in prj.conf file to remove it. But even then the warning remains.
Apart from that there are other warnings like the following
and nobody could give me a solution that works.
I did not even dare to add zephyr drivers in main.c and start writing code since I was overwhelmed...
My experience so far is rather bad...
Dear Nordic semiconductors, how do you expect firmware developers to be productive with your products but on the other hand your software has bugs that makes productivity a very difficult thing.
I know that developing software is not easy at all, but at least, do not recommend the nRF Connect SDK with VScode if it is not ready yet... at least segger studio worked flawlessly even if the nRF52 SDK was a complete mess.
I have wasted a full week only to try and understand what I am doing wrong with v2.6.1 but then it appeared that it has been version bugs.. and then things that were supposed to have been solved in version 2.8.0 are still present.
My humble recommendation to you would be to create a version that WORKS and it is STABLE and then you can recommend it for new designs. If by running a simple hello_world example with nRF Connect SDK with VSCode produces 6-8 warnings only by following the basic course, imagine what will happen when a developer will start adding their own drivers, BLE stack etc....
It should be a more straight forward process... at least not to have that type of bugs
Thank you for your time!