Recommended
Related

Developing Nordic nRF51 Projects with Visual Studio

ivan

This tutorial shows how to create and debug a basic project for the Nordic nRF51-DK using Visual Studio. Before you begin, install VisualGDB 5.0 or later.

  1. Start Visual Studio and begin creating a new project using VisualGDB Embedded Project Wizard:![](http://visualgdb.com/w/wp-content/uploads/2015/08/nordic.png)
  2. Proceed with the default settings on the first page of the wizard:![](http://visualgdb.com/w/wp-content/uploads/2015/08/binary.png)
  3. On the next page of the wizard select the ARM toolchain. If you have not installed it yet, VisualGDB will install it automatically.![](http://visualgdb.com/w/wp-content/uploads/2015/08/armtoolchain.png)
  4. If you have not created Nordic projects before, click "Download Support for More Devices" and select the Nordic package in the list:![](http://visualgdb.com/w/wp-content/uploads/2015/08/nordicdev.png)
  5. Select your nRF51 device from the list and click "Next":![](http://visualgdb.com/w/wp-content/uploads/2015/08/devsel.png)
  6. On the "Sample" page of the wizard select the LEDBlink (BSP) sample and then select an evaluation board you are using from the list. This will automatically configure board-specific settings like LED locations. The board type is normally printed on a sticker on the board. E.g. for nRF51-DK, it is PCA10028. ![](http://visualgdb.com/w/wp-content/uploads/2015/08/sample.png)If you are not using a Nordic evaluation board, select the "LEDBlink" sample and specify the LED port number manually.
  7. Select a debug method compatible with your board. The nRF51-DK board comes with an on-board Segger J-Link device that can be used by selecting the "Segger J-Link" debug method and specifying the location of the Segger J-Link software package:![](http://visualgdb.com/w/wp-content/uploads/2015/08/jlink.png)If you don't have the Segger J-Link software installed, you can get it here.
  8. Press "Finish" to complete creating your project. Then build it via Build->Build Solution:![](http://visualgdb.com/w/wp-content/uploads/2015/08/build.png)
  9. Many of the functionality in Nordic projects is implemented using preprocessor macros. You can quickly expand a certain macro by right-clicking on it and selecting "Preprocess selected lines":![](http://visualgdb.com/w/wp-content/uploads/2015/08/lens1.png)
  10. Press F5 to load your program into the nRF51 chip and observe the LEDs. If you have selected the BSP-based sample, all LEDs on your board will turn on and off one after another:![](http://visualgdb.com/w/wp-content/uploads/2015/08/board.jpg)
  11. Set a breakpoint at the LEDS_INVERT() line and open the Debug->Windows->Hardware Registers. Then step over the LEDS_INVERT() line and observe how the GPIO register values change:![](http://visualgdb.com/w/wp-content/uploads/2015/08/hwreg.png)
  12. Press Shift-F5 to stop debugging. If you look in the Solution Explorer, you will notice that the project includes a lot of auxiliary code from the Nordic SDK. If you want to remove some of the code that is not used (or add other libraries such as various Bluetooth LE protocols), open VisualGDB Project Properties and go to the Embedded Frameworks page where you can select and customize the frameworks used by your project:![](http://visualgdb.com/w/wp-content/uploads/2015/08/frameworks.png)

  • Strange, the reply to last comment got posted in front of the other comments, perhaps there's a bug in the commenting engine?

  • Thanks for the kind words Einar, we did our best to create a really intuitive tool. Regarding your questions:

    • VisualGDB can automatically manage Nordic libraries because the Nordic SDK version that is installed with VisualGDB has matching XML files defining the location of examples and libraries in the SDK. If Nordic releases a new SDK, we would need to recheck all the paths and update our XML files to that VisualGDB can manage everything automatically. On the other hand, if Nordic guys could include a few small XML files with their SDK (and run our BSP validator tool to check for broken paths), VisualGDB could work with that SDK without any further modifications.
    • VisualGDB generates self-contained GNU Make files, so you can open a VisualGDB project on any machine that has GNU Make and the ARM Compiler and build it via command line.
    • VisualGDB is not only ready for serious commercial development, but it is already widely used by many companies around the globe to develop code for platforms like STM32 and Linux-based devices like Raspberry Pi. Now that we have added the nRF51 package, all that functionality became available for the developers using Nordic devices. The way to convince someone to use VisualGDB really depends on their profile and expectations. Developers familiar with Visual Studio typically find other embedded IDEs less functional and seeing the out-of-the-box support for their platform is usually convincing enough. Those who are not familiar with the advantages of VS could find an overview of Debugging features and IntelliSense features quite compelling.
    • Regarding nRF52, we will observe its popularity compared to nRF51 and extend our package once the popularity becomes comparable. Unless someone from the community would like to extend it earlier (our tool that scans the SDK and generates the XML files is open-source and available on GitHub)

  • This is very promising. I used 5 minutes to follow the guide and the first example I tested worked smoothly. The IntelliSense is brilliant, and the debugger is indeed very intuitive. The other nRF51 tutorials on your website are also good.

    After playing with VisualGDB today I have a few questions:

    • Is it possible to specify SDK version manually? Preferably it should be possible to point to any directory where I have installed the vanilla SDK downloaded from Nordic.
    • Is it straight forward to combine using Visual Studio with VisualGDB and building / debugging from the command line using the same Makefiles etc.?
    • Would you say VisualGDB is ready to be used for serious commercial development for the nRF51 target? If not, what is missing? And if yes, how can you convince someone about to start a project to use VisualGDB?
    • Do you have plans to add support for the nRF52?

    Best regards, Einar

  • The main advantage of Visual Studio is much better IntelliSense. VisualGDB projects for devices like nRF51 use Clang-based IntelliSense that can automate things like create-from-use and quickly navigate through the manufacturer's libraries using Code Map.

    It also has a more intuitive debugger that makes it very easy to just hover the mouse over a variable and quickly explore its contents in depth. One other thing would be support for numerous third-party plugins (e.g. IDE integration with SVN or Git).

  • Wow cool!! I never knew developers can work with Visual Studio for their embedded projects.

    In your experience, what IDE do you prefer?

    This Visual Studio, Keil uVision, IAR, or etc.?

    It is just a matter of preference, but I'm curious what's the pros for using Visual Studio.

    -Best Regards, Mango922