Visual Studio corrupts project when switching between projects

[SteveHx]

I am using the nRF52832 in several projects for several different clients. I have created a "project" under Visual Studio using VisualGDB for each one, using the automated build process. Every time I switch from one project to another, I get a VisualGDB warning "Could not locate BSP with ID.....". Choices presented are "Download BSP", "Use version x.xx", or "Locate BSP". I have tried all three at various times; I inevitably end up in another nightmare, killing a couple hours, trying to get the project back together and all the mysterious include files pulled from the right places. Surely the tools can't be THAT amateurish as to preclude multiple parallel projects, so I must be missing something.

1) Why does the message pop up, and why is it not resolved when I load the latest version to all projects?

2) Where do I set the various include paths (which in true Microsoft style, is at least a dozen directories deep)?

3) Is there a better way to do real world development?

Steve Hendrix

[SteveHx]

After beating on this for a couple days over at VisualGDB support, I have reinstalled VisualGDB and the Nordic BSP, with some tweaks to the directories, and now I can compile a new project and can switch between projects smoothly. However, with v15.3 of the Nordic support, new projects don't get NRF_LOG_INFO etc. displaying to the serial port. The project that I was previously using works fine in that regard, so I know the hardware is okay. Is there something special needed in the switches when creating a new project?

[Patrick]

First, verify that your sdk_config.h contains the necessary defines for log output. With new projects I do not believe that logging is enabled by default. Search for NRF_LOG_ENABLED and set it to 1. If you take a look at the sdk_config.h in the lpcomp example search for NRF_LOG_BACKEND_UART_ENABLED and copy the entire section to your project's sdk_config.

[SteveHx]

The basic problem is that the new project wizard does not include sdk_config.h at all any more. Where is the migration guide you mentioned? I've had a horrid time throughout with the documentation - too much fluff, with the real info scattered amongst too many documents.

[Patrick]

Are you sure sdk_config.h is not under Header Files in Solutions Explorer? Worst case I would suggest copying one over to your project from one of the examples and report this to the Sysprogs folks as sdk_config is integral to these projects. I just created a new project based on the blinky example and it has a sdk_config so I'm wondering if you are still having tooling issues.

The migration guide is not a path that needs to be explored here as I found the defines for the logging backends and updated the reply that you responded to.

[SteveHx]

Nope. sdk_config.h is not only not anywhere in the Solutions Explorer tree, it's not called for in any of the files that should be including it. It's as if the project creation process for 15.3 completely excludes the use of NRF_LOG_INFO etc. for writing to the serial port.

I think you're onto something with blinky. I tried duplicating that, and I get a solution that does not include sdk_config.h anywhere in the tree, does not talk on the serial port, and never advertises on BLE. Please check me on the following brief summary of my process:

<File> New Project
   Embedded Project Wizard
   Accept default project name, point directory to my working directory, check "Create directory"
   Click OK

Project Type, Create a new project, Embedded Binary, MSBuild, C++11 with GNU extensions
Next

Here's where I could be going off the rails....

Device Selection
   ARM in C:\SysGCC\arm-eabi (I recall this being the same I've always used)
   Select device from a list - nRF52832_XXAA (there's also an (IoT) option, but that leads me astray)
   Accept all the defaults, Next

Sample Selection
   Switch from Basic samples to Nordic SDK Samples
   The application I'm trying to port was originally built from BLE_APP_CGMS_PCA10040_S132 for historical reasons that aren't relevant here.
   To match your test, I select BLE_APP_BLINKY_C_PCA10040_S132
   Next

Debug Method
   Accept defaults
   Finish

Results as described above.

Am I doing something stupid in the creation process, or should I uninstall everything and reinstall it yet again?

Hmmm....I just checked to confirm my earlier statement, using a global search for sdk_config as I did before. Results are different now. Three files attempt to include it (apparently successfully): nrf_ble_scan.c, nrf_sdh.c, and SEGGER_RTT_Syscalls_GCC.c.

Looking in the first of those, I see
   #if NRF_MODULE_ENABLED(NRF_BLE_SCAN) that would preclude inclusion of sdk_config.h.
I see that NRF_MODULE_ENABLED is just a wrapper, and NRF_BLE_SCAN is not defined anywhere.

Am I supposed to be defining a compile-time variable in the build environment, to enable NRF_LOG_xxx? Why isn't such being done automatically? I never had to do anything like that manually before.

Thanks in advance for any light you can shed on this monster.

[SteveHx]

That's apparently not it. I tried defining NRF_BLE_SCAN in the build environment, and whether or not i do, NRF_MODULE_ENABLED(NRF_BLE_SCAN) is definitely true and the relevant sections are being compiled.

[SteveHx]

Despite not appearing in the build tree, sdk_config.h is definitely present, and NRF_LOG_BACKEND_UART_ENABLED is set true. What is the apparent alternate interface, that's enabled by NRF_LOG_BACKEND_RTT_ENABLED (which is definitely false at present).

[Patrick]

Your project creation process looks correct to me. I walked through your process choosing the same options except used the BLE UART example as the 15.3 BSP I have installed is not the BSP provided by Sysprogs and I do not have a list of Nordic examples to choose from.

Having said that, the example I chose again has sdk_config.h included...

If you look in your project's working directory you should have a local sdk_config in there? Have you verified this?

As far as I am aware there are no compile-time defines that you need to add for logging to work.

[SteveHx]

I definitely have an sdk_config.h in my project directory, but it's not referenced in the project dependency tree, even though it's in fact being compiled into several separate .c files.

Thanks for confirming that I don't need to define any compiler variables externally.

You have turned up at least a clue. If I choose the BLE UART example I get the same as you, with the sdk_config.h file in the tree. Something's fish that it doesn't happen using the Nordic examples. I will explore this more in the morning.

Thanks for the help.

[CurtisHx]

Visual Studio will look in all of the directories listed in the Additional Include Directories in the Project Properties.

There is most likely a sdk_config.h file within one of those folders.

You can also find the location of sdk_config.h by right clicking any of the "#include <sdk_config.h>" directives, and selecting "Open document 'sdk_config.h'".  This will open the SDK file.  Hover the mouse over the open tab and it will give you the full file path.  In addition, you can right click the tab and select "Open containing folder" to open the folder where 'sdk_config.h' is located.