NRF52 dk to 52810 - basic setup help... please

[Dark Monk]

Hey, 
Brand new to this but long time programmer and I sware I have been trying tons of stuff for 4 days straight now and only posting because I am out of options. 

My goal is just to get blinky working on my custom 52810 board, using the NRF52dk using Segger (5.30a) and NRF Connect (1.4.1). Simple right... AHHHHH 

I can compile Blinky, using the simulation 810 settings and get it to work on the 52dk just fine.  
Using a JAG interface, I can download the code, with the two variables removed (DEVELOP_IN_NRF52832 and NRFX_COREDEP_DELAY_US_LOOP_CYCLES) and it appears to load the code on my custom board. I can see that something is loaded on the chip through the Programmer interface tool (read). And that is where I got after 4 days (well learned a ton but still). 

I can not figure out:
1. How to get changes I make to the dts file, for led pin assignments to be included in the compiled code. I see that the file is changed, but when I build the project and even just download it to the 52dk, the pin assignments don't change. In nrf52dk_nrf52810.dts I change "led0 gpios = " to <&gpio0 18 GPIO_ACTIVE_LOW> (instead of 17) and the LED that blinks on the 52dk is still the same one. Is there some other place to change the pin assignment? Do I need to do some sort of compile on the dts file separately from SEGGER? This doesn't feel like it should be so hard. 

2. With the above item figured out, I believe I can create a custom board definition for my 52810, just changing up the pin, button and io assignments in the nrf52dk_nrf52810.dts. Is that correct or do I need to make a custom_board.h file, like the older SDK documentation says? It looks like the new dts file stuff has taken over the need to do the board.h file, but I really can't find good documentation about this. 

3. WHY DOES the blinky example open in Segger (Open NRF SDK PROJET) with all the include directories and just weirdly, such that you can't access the pre-processor options stuff, like you can when opening the nRF_Samples project. I SEARCHED FOREVER to find the segger options menu that included the pre-processor options (and a ton of other stuff) that are in a lot of videos. The nrf samples projects has multiple configurations and gives you a ton more project options (like easily removing the DEVELOP_IN_NRF52832 and NRFX_COREDEP_DELAY_US_LOOP_CYCLES pre-processor options instead of having to manually edit the project make file - which I am not sure worked correctly). Please tell me I can use a structure like the NRF_Samples project and not blinky to develop in.  

4. What UART terminal interface and software stack changes or examples do I need to use to connect directly to my 52810 board that I can send and receive UART coms from just to know if the chip is working? I see a lot of BLE debug tools (which look great), but I need to do some very basic checking to see if any of my code is even running on the chip. I have the UART interface setup mechanically. But don't know if there is an example program you would recommend to just be able to do very basic call and response messages to the chip to see if it is working. I am assuming the same code would work on the 52dk, correct?

THANK YOU SO MUCH for helping me with this. I am sorry to ask such basic questions but I am starting to pull what little hair I have left out and I am betting it is something really basic that I am missing. 

[Carl Richard]

Hi, Dark!

Great that you are progressing with help from Simon's tutorial. I will make sure to let him know! I will also forward your comments on our documentation internally, so that we hopefully can update it to be more informative. As for your questions:

1. As you noticed the project must unfortunately be reloaded with changes to the dts files, but generally it should not be necessary to change the dts file as you can use a .overlay file instead. These are project and board specific files that are used to provide alternative configurations for the peripherals defined in the board definition. 

2. Using the .overlay files I think you can avoid creating an entirely new board file, as the changes required for your custom design can be defined there. There are several usage examples among the nRF samples in the SDK, you can for example look at "<ncs_root>/samples/nrf9160/udp". In your case, the overlay should be named "nrf52dk_nrf52810.overlay". 

3. Could you elaborate on this a little? When using "Open nRF Connect SDK project" it should be possible to update the configuration and pre processor options using "Project/Configure nRF Connect SDK project..." and by right clicking the "Project 'app/libapp.a'" and selecting "Edit Compile Options".

4. You are correct in your assumption that your device can be debugged directly from SES. In addition you can do logging over the Segger RTT interface. 

Hope this answers some questions and please reach out if you have any more.

Note that we are understaffed due to the holidays, so you can expect longer respons times. Sorry for the inconveniece and happy holidays!

Best regards,
Carl Richard

[Dark Monk]

Thank you Carl. I finally got blinky to run on my custom board with the 25810 chip (through the debugger only), and posted my success online (it was a struggle to get there). A very experienced Nordic developer contacted me and we got to talking about all the problems I have been having and how incredibly difficult this initial setup has been. Through that conversation I discovered that I was basically using the WRONG SDK (nRf Connect) for what I was doing. I am building a basic LED controller that uses ble on an 25810. From everything I have been able to find since learning this, it appears the nRf5 Sdk is a much better fit for this and a TON easier to setup and use. 

I would REALLY like to see Nordic put out a recommendation guide on when SDK to do what with for the absolute beginner (just a bit frustrated atm that I wasted days on nRf Connect). A lot of the documentation is trying to do a "whole system" documentation approach, and for the beginner we don't have time to read everything to get a full understanding of it all and then make key decisions like which SDK to use. Simon's tutorial is SO AWESOME, because it walks you through learning specific parts by actually doing the most common things needed and explains just the parts you need and and just the right level. It is education focused not documentation focused. It is the difference of focusing on the reader vs what the writer wants to publish. 

I started researching the nRf5 SDK and found this GREAT youtube series (link below for anyone interested). That is probably the most helpful stuff Nordic could have for learning the SDK for beginners. There really needs to be something like this on what SDK and chip to use for different levels of application dev. This will make your products much more accessible to the newer maker / developer who are mainly looking at Arduino and lower end competitors (who are getting better all the time). If there is going to be two main SDKs that both look like they are going to be used indefinitely, PLEASE document in the tutorials and posts which one is being solved for (dts files don't exist in nRf5 for example) and have some guides on which to do what with for the people that are brand new to this stuff. It is VERY confusing and hard to get started in with the current training methods (more of a documentation than training approach).  

https://www.youtube.com/playlist?list=PLiKJljyEUlZj4z8RqJKTaoMpSqjLdBGO4

I will be switching to nRf5 this weekend and expect to have MUCH fewer problems with initial setup or even writing my application. Guessing all of the above problems will be solved with this also. 

Again, THANK YOU for taking the time to respond and I hope this feedback helps Nordic which will also be helping folks like me. 

[Carl Richard]

Hello again!

My pleasure. Great to hear that you finally got it up and running and thanks for your the elaborate description of your experience. That is valuable for both us and other customers! There is unfortunately some confusion regarding the differences between our two SDKs and we should strive to make their differences clear. While the nRF Connect SDK does support the nRF52 series, we still recommend using the nRF5 SDK for these devices as it's much more mature, with more support material. You could not know this on beforehand, though.

I will make sure to bring up your comments internally.

Also, make sure to dig through our tutorials here on DevZone. For example this one on the nRF5 SDK as well as the user guide for nRF52810 development on the infocenter.

Have a good day and best regards,
Carl Richard

[Dark Monk]

Thank you again Carl. I installed and played with the nRf5 SDK last night and was able to setup my custom and get blinky to run on it, in just under 2 hours. It took over 5 days with the nRf Connect SDK and me being a complete noob. That the nRf5 SDK install tool chain includes installing nRf Connect for the programmer, is probably a place where confusion can happen pretty easily. Unless you really read closely, it does look like the nRf Connect SDK is your latest and greatest and recommended for new development. Again, thank you for your feedback and the incredible work the Nordic team is doing.      

[Carl Richard]

Good to hear. I agree that the liknes between the "nRF Connect Programmer" and "nRF Connect SDK" probably is a source of confusion that should be dealt with. 

It was my pleasure. Good luck with your project and happy new year!

Best regards,
Carl Richard