Introduction

The Microsoft sponsored MT3620 communicates using a WiFi connection and in a development or static environment this isn’t an issue, but when deploying in a dynamic field environment, can be because accessing a dynamic WiFi environment and updating the security credentials may be location dependent. Recognizing this problem, Microsoft offers an example on their Github web-site (https://github.com/Azure/azure-sphere-samples) that shows how to configure a Sphere devices WiFi network using a Bluetooth connection.  The sample that Microsoft provides utilizes:

1. A Nordic nRF52 Development Board
2. A Seed Development Board
3. A PC running Windows 10

The Microsoft solution uses a Seed Development Board but I wanted to use an Avnet Sphere MT3620 Starter KitAvnet Sphere MT3620 Starter Kit (AvnetSK) so it was necessary to port the Microsoft Sample. This required addressing the following differences:

1. The Seed Development Board has more LED’s (that the sample uses) than is available on the AvnetSK.  So the code will be modified to alternately blink the LEDs between the Status Color and the User LED Color.
2. To connect to the AvnetSK, I wanted to use the MikroE Click Board sockets that available.  While Click Socket #2 supports all UART interfaces (RX/TX/RTS/CTS), Socket #1 doesn't and I wanted to allow the use of either Socket.  To support both sockets, the hardware interface must be reduced to its minimum—RX/TX/GND; and it will also require modifying the nRF52 firmware to remove the hardware flow control requirment.

The following Blog describes these changes, how to rebuild the nRF52 firmware, and how the modified Sample operates on the AvnetSK.  All the source code/project file changes discussed in this Blog are contained within the Avnet Github repository at https://github.com/Avnet/WifiBLE.  To download and use, simply issue the following command:

git clone https://github.com/Avnet/WifiBLE

Overview

The following is a "big picture" view of the current solution:

The Microsoft Sample includes a basic Windows Application that uses the Windows Operating System to communicate with the Nordic nRF52 board.   In turn, the nRF52 board communicates with the Azure Sphere board via a UART, message exchanges between the Sphere Board and Windows Application demonstrate the remote management capabilities.  It is worth noting, that even though the Sphere SDK provides API's for numerous features, the current Sample solution only uses those that start with ‘Wifi’ (e.g., WifiConfig_ …).  It wouldn't be to difficult to extend the messaging to be inclusive of other API's if desired.

Modifying and re-building the Nordic firmware

The Microsoft Sample software uses hardware flow control but because the length of messages exchanged are rather small, it isn't really necessary. Additionally, the DFU (download firmware update) pin is not needed for this Sample (I found that these pins are used in other Sample software that uses the nRF52 so I suspect the current firmware implements it to support those other Samples). To achieve a the minimal hardware interface, both the Sphere board Sample code and nRF52 source code (located in the 'Nrf52App/nordic/uart_utilities.c') must be modified.  For the Nordic nRF52, the code changes are limited to removal of the hardware flow control as shown below.

void uart_init(received_uart_data_handler_t received_uart_data_handler)
{
    m_received_uart_data_handler = received_uart_data_handler;


    uint32_t err_code;
    app_uart_comm_params_t const comm_params = {
        .rx_pin_no = RX_PIN_NUMBER,
        .tx_pin_no = TX_PIN_NUMBER,
        .rts_pin_no = RTS_PIN_NUMBER,
        .cts_pin_no = CTS_PIN_NUMBER,
        /* .flow_control = APP_UART_FLOW_CONTROL_ENABLED, */
        .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity = false,
#if defined(UART_PRESENT)
        .baud_rate = NRF_UART_BAUDRATE_115200
#else
        .baud_rate = NRF_UARTE_BAUDRATE_115200
#endif
    };


    APP_UART_FIFO_INIT(&comm_params, UART_RX_BUF_SIZE, UART_TX_BUF_SIZE, uart_event_handle,
                       APP_IRQ_PRIORITY_LOWEST, err_code);
    APP_ERROR_CHECK(err_code);
}

.

After changing the nRF52 source, rebuild the firmware, combine it with the SoftDevice firmware (that is provided in the Nordic SDK) and reload it onto the board. To accomplish these tasks, you must download the Segger embedded Studio, the Nordic NRF5 SDK, and the Nordic nRF command line tools:

1. Download and install the SEGGER Embedded Studio (use the 32-bit version, not the 64-bit version). You can obtain a license if you are developing code for the nRF52 (which we are).

2. Download and Install the Nordic NRF5 SDK V15.2.  Ensure you download v15.2 as newer releases are likely available but this is the version that was used for this sample code.

3. Download and Install the Nordic nRF5x Command Line Tools.  You need to this so you can have the mergehex tool which is used to combine the image you produce with the Softdevice hex file provided in the SDK.

After the SDK is installed, go to the embedded studio project file (WifiSetupAndDeviceControlViaBle\Nrf52App\pca10040\s132\ses\ble_app_uart_pca10040_s132.emProject) and set the SDK_ROOT variable to point to the root directory of your Nordic SDK install. Specifically, replace the words "CHANGE_THIS_TO_YOUR_NORDIC_SDK_PATH" with the correct path.  NOTE: make sure to use Linux style backslashes ('/') instead of the windows style ('\').

With the tools installed (and after modifying uart_utilities.c), open the emProject file in the Segger IDE and rebuild it (Alt+F7 for a full rebuild).

The output from the Build is located in the \Nrf52App\pca10040\s132\ses\Output directory.  The  image will be named ble_app_uart_pca10040_s132.hex and this HEX file should be combined with the Softdevice that is provided in the SDK (nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_dfu_test_images\uart\nrf52832).  To combine these two files, use the mergehex too that is part of the Nordic nRF5x Command Line Tools, e.g.:

mergehex -m nRF5_SDK_15.2.0_9412b96\components\softdevice\s132\hex\s132_nrf52_6.1.0_softdevice.hex .\ble_app_uart_pca10040_s132.hex -o combined.hex

NOTE: An already built version of the modified firmware is located in the Binary directory of the project

Next, program this HEX file into your nRF52 Development Board as described in the Microsoft documentation.

Azure Sphere Source Code

The following files have been changed to support the AvnetSK.  These files are located in the WifiBLE\AzureSphere_HighLevelApp\WifiSetupAndDeviceControlViaBle directory:

With these changes, compile the code by:

1. Opening the AzureSphere_HighLevelApp/WifiSetupAndDeviceControlViaBle.sln file in Visual Studio.
2. Build and debug the application (F5). Wait for application to build and download to the Sphere Device.
3. Once downloaded and started the output window will reflect the status of the Sphere Board.  Initially, it will be advertising to connect, known BLE devices and the LED will be flashing blue.

Running the Azure Sphere Application

At this point, the AvnetSK will only connect to previously bonded devices.  For the initial connection however, it must allow connections to ANY BLE device.  To do this, we first need to obtain the device name which is generated and displayed in the Output window in Visual Studio during startup (the name will look something link Azure_Sphere_BLE_123456).  There are actually two steps that are necessary to run the Sample Application:

1. Pair the nRF52 board to the Windows OS
2. Run the WindowsApp that comes with the Sample to execute commands and obtain status

Occasionally, the Sphere Board responds (in the output window) with:

 

INFO: SAMPLE_BUTTON_1 was pressed briefly, allowing new BLE bonds...
ERROR: Unable to allow new BLE bonds, check nRF52 is connected.
INFO: set_statusLedcolor called with color=2

 

When this occurs depress and hold the RESET button on the nRF52 to restart the nRF52 firmware (while the Sphere Application is running). The Sphere Board should then successfully find the nRF52 board.  This problem occurs because the two boards (nRF52 and Sphere Board) each start independently of each other and are not in correct states relative to each other.  By depressing the nRF52 RESET button while the Sphere Board is running, it causes the nRF52 board to recognize and use the Sphere Board.  If it starts prior to the Sphere Board running, it doesn't know to use it.

NOTE: sometimes it may also necessary to restart the Windows Application if it fails to connect.  This occurs due to caching.

Generally, the following steps are a very repeatable sequence for bonding the Windows PC with the nRF52/Sphere Board.

1. Using the Windows PC, Open the Bluetooth Devices dialog located in the Windows status bar
2. After the dialog is opened verify that no previously attached instances exist. If they do, delete them.  It is helpful to also restart the Windows Application at this point to ensures that the all components are starting from a clean beginning point with no previously cached connections.
3. On the AvnetSK, press and hold Button A to erase all previously paired devices.  This sends a command to the nRF52 that removes previously cached configurations.
4. Again on the AvnetSK, press and release Button A to allow a new Bluetooth connection to be established (sends commands to the nRF52 board to allow new connections).
5. Lastly, on the Windows PC, select the 'Add Bluetooth or other device' and select the Azure Sphere device name when it is displayed.  After doing this, you will be prompted to enter a PIN to bond the device--the PIN is located in the output window.

The sequence of events displayed in the Visual Studio Output windows will be similar to:

After you have entered the passkey, the nRF52 will pair with the Windows PC and you can use the Sample Windows App.

Connecting the Windows App to the AvnetSK

1. Now that Windows and the nRF52/Sphere Board are connected, start up the Sample Windows App by compiling and running it (use the instruction contained in the Sample README.md).
2. After it starts, you can "Scan for devices"  and find your previously bonded Azure_Sphere_BLE_999999 device.  Select it and the App display will show that you either need to Add new network... or the details of the currently connected network.
   1. If no active WiFi network has been established (as shown), select "Add new network..." to perform a WiFi scan then Select the appropriate Network, enter the security key (if needed) and the Starter kit will be connected
3. Details of the connected WiFi network will be presented in the Windows App

At this point, you are successfully connected to the WiFi network.

You can also use either the LED button in the Windows App  or Button B on the sphere Board to control the User LED (regardless of the WiFi connection status).  If the User LED is enabled, the LED will alternately flash WHITE and the WindowsApp button will be green.  Conversely, if it is disabled, the LED will not flash and the WindowsApp button will be WHITE,

Wrap-up

Porting the Microsoft Sample to the AvnetSK proved to be a straightforward task but getting the inter-working of all the components can be confusing. Hopefully this Blog helps to show how the parts are connect and demonstrates the mechanics of getting a working system up and running quickly--even if you have to do some porting. As always, comments and questions are welcome...