• State Not Answered
  • Locked Locked
  • Replies 0 replies
  • Subscribers 64 subscribers
  • Views 3803 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101240
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Running Nordic BLE code in Visual Studio Project

Adrian Eggenberger

This is not a real question for support. It's more a success story i'd like to share with you!

Our company develops firmware for various customers on a lot of different hardware platforms. In all these projects we had a simulated firmware project beside the project on the compiler IDE. These simulations run on visual studio and the code in the logic or GUI layer is equal to the real firmware project. This allows us to develop up to 95% of the code in visual studio without real hardware and with the enhanced visual studio debugger.

Last year BLE came up into a few of our projects and we decided to use the Nordic nRF51822 chip. The upcoming question was: How to integrate BLE/SoftDevice 110 in our simulated firmware?

After a few tests we gave the S110 serialization a shot. The Nordic SDK has in the folder "ble_s110_serialization" a example for this running on two hardware platforms. The attached graphic shows our way to integrate BLE in a simulated firmware using the S110-Serialization. The core part of this serialization is the S110-RPC code which includes the encoder/decoder for the S110 remote procedure calls (RPC).

The easier side was the USB-Dongle. The SDK-Project "ble_app_connectivity" is exactly what we needed. Only one small extension was added to the project (see below). We took our PCA10000 Dongle and flashed a "ble_app_connectivity"-Firmware to it. The dongle now accepts SLIP/HCI commands from the Nordic S110 Serialisation Code on its UART over USB-Interface.

The more difficult part was to run the BLE code in a Visual Studio Project. Running the Nordic and custom BLE code on Visual Studio turned out to be more difficult than expected. The following main problems had to be solved:

  1. Target Includes The Nordic SDK has support for various target compilers, but support for a visual studio c-compiler (define "MSC_VER") is missing. A few changes to the SDK files had to be done (less than I expected first) to fix issues with hardware related defines and definitions.

  2. C89 compatibility The Visual Studio 2012 still has no C99 support. The most required files in the Nordic SDK work properly in a visual studio project, but especially in the S110-Serialization code some C99 features are used (mostly variable definition not at the start of a code-section). To fix these was easy problems was easy.

  3. Add missing S110 functions to the RPC-Code The provided RPC code from the Nordic SDK includes a lot of functions from the S110, but some sd_xyz functions are missing. I had to add the required functions to the RPC encoder/decoder. The extension of more commands was not too hard, because the provided SDK code is prepared properly for more supported functions.

  4. Bind S110-RPC Output to a serial port The S110-RPC code interferes with the HCI transport layer for transferring RPC-packets between the two systems. After a few tests with the provided HCI and SLIP implementation from the SDK we decided to implement our own HCI/SLIP code. The reason is, that the provided code is not able to handle immediate transmit complete feedback. Our simulated serial port functions would synchronously call the transmit complete function of the upper layer, because the data has been sent the the windows serial port API. The provided code is not capable to handle these immediate transmit complete. I was wondering about this, because it may be a problem on real hardware too. If a real hardware system has to serve some other interrupts after calling the transmit functions the transmit complete may also be called before the transmit function has returned to the calling code. I can give some more detailed information on this if needed.

  5. Dongle-Reset As the HCI-Protocol includes framing it is important, that both side reset at the same time. Otherwise the frame numbers would be wrong. On a target platform a reset of the client side would probably reached by pulling the reset line of the client or is done automatically at system startup. In the environment with a USB-Dongle we need another way for doing this. We added a special sequence to the SLIP protocol that can be sent and triggers a reset in the USB-Dongle.

After fixing these issues the BLE-Services and the BLE-Management (Advertisement, Connection-Parameter) code was running properly in the simulated device. The calls to the softdevice are coded by the S110-RPC and sent to the BLE-USB Dongle. The sd_xyz function waits for the answer of the USB-Dongle and returns the received answer. Overall we now have a working simulation of our BLE based firmware!

I would like to thank Nordic for the really good code in the SDK and specially for implementing a S110-RPC library. It would be awesome if some of our fixes (see point 1 - 5) could be integrated in an upcoming SDK version. If you are interested just send me a message.

Best Regards Adrian

S110-Simulation.png

Related