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.