Introduction FP-CLD-AZURE1 is an STM32Cube function pack which lets you safely connect your IoT node to Microsoft Azure IoT, transmit sensor data and receive commands from Azure cloud applications. It fully supports Azure device management primitives and includes a sample implementation for firmware update over the air (FOTA). By using a mobile device with NFC, Wi-Fi connectivity link is easily configured. This software, together with the suggested combination of STM32 and ST devices, can be used, for example, to develop sensor-to-cloud applications for a broad range of use cases, such as smart home or smart industry. The software runs on the STM32 microcontroller and includes drivers for the Wi-Fi connectivity, dynamic NFC/RFID tag and motion and environmental sensors. Getting started with the FP-CLD-AZURE1 software for IoT node with Wi-Fi, NFC, sensors and motor control, connected to Microsoft Azure IoT UM2043 User manual UM2043 - Rev 7 - January 2019 For further information contact your local STMicroelectronics sales office. www.st.com
Transcript
IntroductionFP-CLD-AZURE1 is an STM32Cube function pack which lets you safely connect your IoT node to Microsoft Azure IoT, transmitsensor data and receive commands from Azure cloud applications.
It fully supports Azure device management primitives and includes a sample implementation for firmware update over the air(FOTA). By using a mobile device with NFC, Wi-Fi connectivity link is easily configured.
This software, together with the suggested combination of STM32 and ST devices, can be used, for example, to developsensor-to-cloud applications for a broad range of use cases, such as smart home or smart industry.
The software runs on the STM32 microcontroller and includes drivers for the Wi-Fi connectivity, dynamic NFC/RFID tag andmotion and environmental sensors.
Getting started with the FP-CLD-AZURE1 software for IoT node with Wi-Fi, NFC, sensors and motor control, connected to Microsoft Azure IoT
UM2043
User manual
UM2043 - Rev 7 - January 2019For further information contact your local STMicroelectronics sales office.
• Complete firmware to safely connect an IoT node with sensors to Microsoft Azure IoT using Wi-Ficommunication technology
• Middleware libraries featuring the Microsoft Azure IoT software development kit, NFC connectivity, transport-level security (mbedTLS), and meta-data management
• Ready-to-use binary to connect the IoT node to ST web dashboard running on Microsoft Azure for sensordata visualization and device management (FOTA)
• Ready-to-use binary to connect the IoT node to a personal subscription on Azure IoT Central solution with"sample contoso" template
• Sample implementations available for STM32L4 Discovery Kit for IoT node (B-L475E-IOT01A) developmentboard
• Easy portability across different MCU families, thanks to STM32Cube• Free, user-friendly license terms
This software is based on the STM32CubeHAL hardware abstraction layer for the STM32 microcontroller. Thepackage extends STM32Cube by providing a board support package (BSP) for Wi-Fi and sensors.The package integrates the Azure IoT device SDK middleware with APIs to simplify interaction betweenDiscovery Kit for IoT node and the Microsoft Azure IoT services. You can use it to prototype end-to-end sensors-to-cloud IoT applications by registering your board to Microsoft Azure IoT and begin exchanging real-time sensordata and commands.A web dashboard based on Microsoft Azure is also provided free of charge to facilitate the evaluation of thefunction pack.It is possible to use the package with a personal subscription to Azure IoT Central solution with the "samplecontoso" template.For Azure license terms, visit https://azure.microsoft.com.
2.2.1 What is STM32Cube?STMCube™ is an STMicroelectronics initiative that helps you reduce development effort, time and cost.STM32Cube covers the STM32 portfolio.STM32Cube version 1.x includes:• STM32CubeMX, a graphical software configuration tool that allows the generation of C initialization code
using graphical wizards.• A comprehensive embedded software platform specific to each series (such as the STM32CubeF4 for the
STM32F4 series), which includes:– the STM32Cube HAL embedded abstraction-layer software, ensuring maximized portability across the
STM32 portfolio– a consistent set of middleware components such as RTOS, USB, TCP/IP and graphics– all embedded software utilities with a full set of examples
2.2.2 What can you do with STM32Cube function packs?The STM32Cube function packs leverage the modularity and interoperability of STM32 Nucleo and X-NUCLEOboards, and STM32Cube and X-CUBE software, to create function examples, embodying some of the mostcommon use cases, for each application area.These software function packs are designed to exploit as much as possible the underlying STM32 ODE hardwareand software components to best fit the requirements of final users’ applications.Moreover, function packs may include additional libraries and frameworks which do not present the original X-CUBE packages, thus enabling new functionalities and creating a real and usable system for developers.
2.2.3 FP-CLD-AZURE1 architecture
Figure 1. Software architecture
The software layers used by the application to access and use the STM32 microcontroller and the Wi-Fi , sensorsand NFC tag are:• STM32Cube HAL driver layer: a simple, generic, multi-instance set of APIs (application programming
interfaces) to interact with the upper layer applications, libraries and stacks. The APIs are based on acommon framework so that overlying software like middleware can implement functions and routines withoutspecific microcontroller unit (MCU) hardware configurations. This structure improves library code reusabilityand guarantees easy portability across other devices.
• Board support package (BSP) layer: drives the STM32 Nucleo board peripherals like the LED, userbutton, etc. (not the MCU), with a specific set of APIs. This interface also helps in identifying the specificboard version.
• Middleware layer: contains the MetaDataManager to save Meta Data in the STM32 Flash memory,mbedTLS, NDEF library to read information from the NFC and the Microsoft Azure IoT device SDK (https://github.com/Azure/azure-iot-sdks) to facilitate the connection of STM32 Nucleo with Azure IoT services.
2.3 Folder structure
Figure 2. Package folder structure
The following folders are included in the software package:• Documentation: with a compiled HTML file generated from the source code detailing the software
components and APIs (one for each project).• Drivers: the HAL drivers and the board-specific drivers for each supported board or hardware platform,
including those for the on-board components, and the CMSIS vendor-independent hardware abstractionlayer for the ARM Cortex-M processor series.
• Middlewares: the middleware interface for MetaDataManager, mbedTLS and the porting of Microsoft AzureIoT device SDK.
• Utilities: contains BootLoader for B-L475E-IOT01A.• Projects contains the Azure1 sample application (for B-L475E-IOT01A) reads sensor data and transmits
them to Micorosft Azure IoT Hub via Wi-Fi, enabling device remote control thanks to the full support forMicrosoft Azure primitive device management. It also contains an example of remote firmware updateprocedure. The project could be compiled also in order to be compatible with the "sample contoso"application template for Azure IoT Central. Sample application can be compiled under the IAR EmbeddedWorkbench for ARM, RealView Microcontroller Development Kit (MDK-ARM-STM32) or System Workbenchfor STM32 development environments. For each sample application, the folder also contains a configurablepre-compiled binary to connect devices with a personal Azure IoT central account with "sample contoso"application template, and another pre-configured binary which can be used together with a companionAzure-based web dashboard for easy sensor data visualization and device control.
2.4 Flash memory managementThe sample application uses the Flash memory to:1. save the Wi-Fi credentials and the IoT Central information in the Meta Data Manager;2. allow the Firmware-Over-The-Air updateTo enable these features the Flash is divided in different regions (see Figure 3. Azure1 Flash structure forNUCLEO-STM32L476RG):1. the first region contains a custom boot loader (required for firmware update);2. the second region contains the application firmware;3. the third region is used in a firmware update procedure to store the new downloaded firmware before
updating it, and to save data inside the Meta Data Manager.
The Meta Data Manager is placed at the end of the Flash (0x080FF000 for STM32L476RG).(For moreinformation on the Flash memory management, refer to Reference manual STM32L4x6 advanced ARM®-based32-bit MCUs (RM0351).
Figure 3. Azure1 Flash structure for NUCLEO-STM32L476RG
2.5 The boot process for the firmware update over-the-air (FOTA) applicationTo enable the firmware update procedure, the Azure1 application binary cannot be flashed at the beginning of theFlash memory (address 0x08000000), and is therefore compiled to run from the beginning of the second Flashregion (at 0x08004000).To enable this procedure, a vector table offset is set in Src/system_stm32l4xx.c (for B-L475E-IOT01A): #defineVECT_TAB_OFFSET 0x4000.The linker script also requires changes; for example, the Linker script for Azure1 running on B-L475E-IOT01A andcompiled using IAR Embedded Workbench for ARM is modified as follows:
/*-Specials-*/define symbol __ICFEDIT_intvec_start__ = 0x08004000;/*-Memory Regions-*/define symbol __ICFEDIT_region_ROM_start__ = 0x08004000;define symbol __ICFEDIT_region_ROM_end__ = 0x0807FFFF;define symbol __ICFEDIT_region_RAM_start__ = 0x20000000;define symbol __ICFEDIT_region_RAM_end__ = 0x20017FFF;define symbol __ICFEDIT_region_SRAM2_start__ = 0x10000000;
UM2043The boot process for the firmware update over-the-air (FOTA) application
define symbol __ICFEDIT_region_SRAM2_end__ = 0x10007FFF;/*-Sizes-*/ define symbol __ICFEDIT_size_cstack__ = 0x6000;define symbol __ICFEDIT_size_heap__ = 0x12000;
Using the above linker script, the maximum usable code size is fixed at 496 KB.Before flashing the compiled Azure1 firmware, you must flash the appropriate bootloader binary for B-L475E-IOT01Ax , available in the Utilities\BootLoader folder, in the first Flash region (address 0x08000000).
Figure 4. BootLoader folder content
When the firmware update procedure is activated, the new firmware is downloaded and copied in the third Flashregion.After board reset, the following procedure applies:• if there is a new firmware downloaded in the third Flash region, the BootLoader overwrites the second Flash
region (containing the current firmware), replaces its content with the new firmware and restarts the board;• if there is no new firmware downloaded, the BootLoader jumps to the firmware stored in region 2.
Figure 5. Azure1 boot sequence
2.6 The installation process for the firmware update over-the-air (FOTA) applicationThe flashing procedure is simplified by a script available for each IDE (IAR/RealView/System Workbench). Thescript writes the compiled firmware and BootLoader in the right memory position.
UM2043The installation process for the firmware update over-the-air (FOTA) application
UM2043 - Rev 7 page 7/42
Figure 6. Project folder content example
In particular, the script:• erases the full Flash;• flashes the BootLoader at the correct position (0x08000000);• flashes the Azure1 firmware at the correct position (0x08004000).
UM2043The installation process for the firmware update over-the-air (FOTA) application
UM2043 - Rev 7 page 8/42
Figure 7. BootLoader and Azure1 installation
The same script also dumps a unique image file (containing the BootLoader and the Azure1 firmware) that can bedirectly flashed to the beginning of the Flash memory.
UM2043The installation process for the firmware update over-the-air (FOTA) application
UM2043 - Rev 7 page 9/42
Figure 8. BootLoader and Azure1 Dump process
For the Linux/OSx operating system there is a similar script, CleanAzure1mbedTLS.sh, that uses OpenOCDinstead of the ST-LINK command lineThe script is included only in the System Workbench IDE and requires:• the installation path for OpenOCD according to the local configuration;• the installation path for STM32 OpenOCD scripts according to the local configuration;• the library path for OpenOCD according to the variable used for Linux/OSx environments.
# 1) Set the Installation path for OpenOCD# example:#OpenOCD_DIR="C:/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.externaltools.openocd.win32_1.10.0.201607261143/tools/openocd/"OpenOCD_DIR=""
# 2) Set the installation path for stm32 OpenOCD scripts# example:#OpenOCD_CFC="C:/Ac6/SystemWorkbench/plugins/fr.ac6.mcu.debug_1.10.0.201607251855/resources/openocd/scripts"OpenOCD_CFC=""
# 3) Only for Linux/iOS add openocd library path to _LIBRARY_PATH:# For iOS example:#export DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH}:${OpenOCD_DIR}"lib/"
# For Linux example:#export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${OpenOCD_DIR}"lib/"
UM2043The installation process for the firmware update over-the-air (FOTA) application
UM2043 - Rev 7 page 10/42
2.7 Azure IoT sample application descriptionAzure1 sample application for B-L475E-IOT01A board is provided in the Projects directory.The board uses an integrated Wi-Fi module and the sample application reads data values from the temperature,humidity, accelerometer and gyroscope sensors and transmits them to the Microsoft Azure IoT Hub via Wi-Fi.The sample application also fully supports Azure device management primitives to remotely control the device,and includes a sample to trigger firmware update over-the-air procedure.Detailed information on how to register a free sample account in Azure can be found at azure.microsoft.com/en-us/pricing/free-trial/.The Azure1 application could be compiled in two different ways according to the define calledAZURE_IOT_CENTRAL included in the Projects\Multi\Applications\Azure1\Inc\azure_config.h file.If the define is enabled, the code creates an application compatible with Azure IoT central "sample contoso"application template; otherwise, the code creates an application compatible with the format used on ST webdashboard using the DPS provisioning system.The NFC expansion board can also be used by the embedded application to read Wi-Fi access point parameters.
2.7.1 Launch sample applicationOnce you have set up your system as per Section 3.3 Hardware and software setup, you can proceed to launchthe sample application provided with FP-CLD-AZURE1.Pre-compiled binaries are available, together with the project files to rebuild the solution.A serial terminal interface is necessary to monitor the log of the sample application and can be used for deviceconfiguration.
2.7.1.1 Serial terminal interface setup
Set up a serial terminal (i.e. TeraTerm) with the parameters reported in the figure below. In particular, set theproper baudrate (115200) and a Transmit delay (10 msec/char).
Figure 9. Serial port configuration
2.7.1.2 Use pre-compiled binaries
Pre-compiled binaries are contained in Projects\Multi\Applications\Azure1\Binaries.
Step 1. The following pre-compiled binaries can be found: Azure_Sns_DM_BL.bin can be configured withcustom parameters for Wi-Fi using serial terminal or NFC and must be used jointly with IoT WebDashboard described in Section 2.8 STM32 ODE web dashboard for FP-CLD-AZURE1. This binary
contacts the STM32 ODE device provisioning system (DPS) to register the board and retrieve theconnection rights to contact the STM32 IoT Web dashboard. Azure_IoTCentral_BL.bin can be usedwith a personal account on Microsoft IoT central (https://www.microsoft.com/en-us/iot-central) andallows visualizing the sensor data using the "sample contoso" application template.
Step 2. Connect your board to the laptop using a Micro-B USB cable; when the board appears as a massstorage device, drag the binary as shown in the picture below.
Figure 10. Drag the binary to the connected board
Step 3. After copying the binary, open the serial terminal to view the device message log (seeSection 2.7.2 Device configuration to learn how to enter credentials).
2.7.2 Device configurationIt is possible to configure the sample application via serial terminal interface or NFC expansion board, or bymodifying the source code to add Wi-Fi access point credentials: SSID, password and security(WEP,WPA,WPA2).After configuration, parameters are permanently stored in the Flash memory and can be overwritten or re-used asdefault configuration after board reset.
2.7.2.1 Configuration via serial terminal
After launching the application as described in the previous section, you can use a serial terminal to configure Wi-Fi/SSID/PassWD and authentication type.
2.7.2.1.1 Wi-Fi access point configuration
Step 1. Open the serial terminal and press Reset.The very first time the board is flashed and the application is launched, the default SSID and passwordare used as written in the code.
Step 2. Press the blue User Button within 3 seconds.Step 3. Press n when asked to read from NFCStep 4. Enter the requested parameters.
Wi-Fi credentials inserted are stored in the Flash memory and used after each board reset, unless theUser Button is pressed.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 12/42
Figure 11. Configure Wi-Fi credentials
2.7.2.2 Configuration via NFCWhen using the B-L475E-IOT01A development board with an NFC-enabled mobile phone, you can use near fieldcommunication technology to configure Wi-Fi.Rebuild solution files before flashing the board, or use the pre-compiled binaries, then follow instructions belowaccording to your board configuration.
2.7.2.2.1 Wi-Fi access point configuration
Step 1. Download the ST25 NFC mobile application on your NFC-enabled mobile phone: (any other mobileapplication able to write NDEF parameters to NFC can also be used).
Step 2. Launch your mobile application to write/read NDEF tags (i.e. ST25 NFC tag)
Step 3. Click on the Wi-Fi button and enter the SSID and password for the access point.Step 4. Then click on the Write to tag button after placing your mobile phone near to the NFC expansion
board.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 14/42
Figure 13. AP parameter setting on the ST25 NFC app
2.7.2.3 Configuration in source code
Wi-Fi configuration and Azure IoT Hub connection string can be directly entered in the source code beforerecompiling the solution file, as described below.
Step 1. Open the solution file according to the selected IDE and platform used.Step 2. Open the file azure_config.h and add a custom value for AZURE_DEFAULT_SSID,
AZURE_DEFAULT_SECKEY, AZURE_DEFAULT_PRIV_MODE.Step 3. Rebuild the solution file according to the selected IDE and flash the microcontroller.
Follow the procedure described in Section 2.6 The installation process for the firmware update over-the-air (FOTA) application.
2.7.3 DICE emulator for robust Internet of ThingsThe device provisioning service (DPS) from Azure IoT uses device identifier composition engine (DICE) androbust Internet of Things (RIoT) for secure device identity and attestation.DPS X.509-based protocols rely on cryptograohic keys and certificates produced by RIoT and the root of trust formeasurement provided by the DICE in the hardware.The Azure1 application contains an adpater to implement the DICE emulator/RIoT included inside the AzureSDK.The adapter is in the dps_hsm_riot_STM32Cube.c file in the Projects\Multi\Applications\Azure1\Src folder andcontains two different versions of certifications-chains:• one in Azure SDK• one used by Azure1 application to connect the FP-CLD-AZURE1 package with the STM32 ODE web
dahsboard.
This adapter contains a define called AZURE_USE_STM_CERT to choose between using ST certificates or thestandard Azure one.The global configuration file azure_config.h has two different defines that works with this adapter:• AZURE_PRINT_CERTIFICATES: if this define is enabled, the Azure1 application prints on the UART
console the three certificates used in the certification chains: root, intermediate and device certificates withtheir public and private key;
• AZURE_PRODUCE_LEAF_CERTIFICATES: if this define is enabled, the Azure1 application is able to createleaf certificates to validate the root and intermediate certificates for group unrolling with Azure DPS systems.
To add and validate new certificates on a personal instance of Azure DPS, it is necessary to modify the adapter(dps_hsm_riot_STM32Cube.c) to create the desired new certificates creating a new public and private key forthe root certificate and to re-compile the code enabling AZURE_PRINT_CERTIFICATES andAZURE_PRODUCE_LEAF_CERTIFICATES.
Figure 14. DPS instance in the Azure portal
After having re-compiled the code and flashed the STM32L4 Discovery kit for IoT node (B-L475E-IOT01A), it ispossible to visualize the new certificate chain created on the UART console.
Figure 15. DPS certification chain on the UART console
It is now possible to copy the root and intermediate certificates to the personal DPS instance.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 17/42
Figure 16. Root intermediate certificates loaded on the DPS instance
After that, you have to validate the new certificates by creating a leaf certificate to boot the root and intermediatecertificate. The Azure1 compiled with the AZURE_PRODUCE_LEAF_CERTIFICATES allows creating the leafcertifcates in sequence for root and intermediate (or signer) ones: for each certificate, it is necessary to select thecertificate inside the DPS instance on the Azure portal and follow the procedure below.1. Generate the verification code.2. Copy and paste the verification code on the UART console: the Azure1 creates the leaf certificate for this
verification code to be saved on a .cer file. This verification code has a very limited life time; so, it isnecessary to execute the steps fast to ensure certificate validation by DPS.
3. Load the created .cer file for leaf certificates on the DPS instance in the Azure portal.4. Press the [Verify] button to verify the certificate.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 18/42
Figure 17. Validate a certificate on DPS instance
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 19/42
Figure 18. UART terminal after leaf certiticates creation
The figure below shows the certificate status inside the DPS instance on the Azure portal after the validationphase.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 20/42
Figure 19. Validated certificates on DPS instance
After that, you can move the Manage enrollments section to create a single or a group enrollment policy.
Figure 20. Enrollment on DPS instance
To enroll a group, you have to select the validated root and intermediate certificates, select the IoT hub connectedto this group enrollments and define an initial twin configuration for the devices enrolled with this certificate chain.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 21/42
Figure 21. Group enrollment on DPS instance
Any device created from now on has a device certificate starting from this certifications chain: it can contact theDPS and obtain the credentials to establish the connection with the decided IoT hub without a connection string.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 22/42
Figure 22. UART output when the device contacts the DPS
2.7.4 IoT Central sample for Azure1 applicationFor B-L475E-IOT01Ax, Azure1 includes a configuration which enables connection to Microsoft IoT Central(https://www.microsoft.com/en-us/iot-central) using the "sample contoso" application template.Microsoft IoT Central is a fully managed SaaS (software-as-a-service) based on Azure that simplifies thedevelopment of IoT solutions. Hands-on material to create a simple application in IoT Central is available athttps://docs.microsoft.com/en-gb/microsoft-iot-central/tutorial-add-device.To enable communication with IoT Central, open azure_config.h then uncomment define AZURE_IOT_CENTRALand recompile the project; in alternative, the pre-compiled binary Azure_IoTCentral_BL.bin can be used.To use the application compiled for the "sample contoso" application template, it is necessary to create a personalaccount on Microsoft IoT Central. After logging inl with the [Application Manager], select [New Application].
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 23/42
Figure 23. Azure IoT Central: create a new application
Figure 25. Azure IoT Central: create a real device
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 25/42
It is possible to change the device name instead of the proposed one.
Figure 26. Azure IoT Central: real device creation
Selecting the created real device, it is possible to visualize the connection parameters. To find them, select[Connect] inside the [Device explorer] after having selected the real device created.
Figure 27. Azure IoT Central: retrieve the connection parameters
The connection parameters are:
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 26/42
1. Scope ID: the scope of the DPS instance for the created "sample contoso" application template. This valueis the same for all the real devices created under the same account.
2. Device ID: the device identification. This value is different for each device created.3. Primary Key: the primary device SAS token. This value is different for each device created.
After having retrieved these parameters, you can run the pre-compiled binary Azure_IoTCentral_BL.bin on the IoTnode (B-L475E-IOT01A). After inserting the Wi-Fi credential access, the board waits for the connectionparameters in the UART console.
Figure 29. Azure IoT Central: connection parameters insertion in the UART console
Note: Parameteres are saved in the Flash memory using the MetaData Manager. You can change them anytime bypressing the [User button] at the boot when the UART asks whether to keep or change the saved values.The board contacts the DPS identified by the Scope ID and retrieves the IoT hub and the device name toconnecting the "sample contoso" application template instantiated. You can visualize the sensor data sent by theboard to the IoT Central.
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 28/42
Figure 30. Azure IoT Central: sensor data
You can also change the Fan Speed under the [Settings] tab receiving the confirmation that the new value issynchronized with the board.
Figure 31. Azure IoT Central: change settings
UM2043Azure IoT sample application description
UM2043 - Rev 7 page 29/42
The [Dashboard] tab shows a report for the real device created.
Figure 32. Azure IoT Central: dashboard
2.8 STM32 ODE web dashboard for FP-CLD-AZURE1A web dashboard based on Microsoft Azure has been created to offer developers a quickstart evaluation offeatures available in FP-CLD-AZURE1.Specific ready-to-use pre-compiled binaries is provided in the FP-CLD-AZURE1 package to connect your boardwith the web dashboard: Azure_Sns_DM_BL.bin.You can access STM32 ODE web dashboard at .
2.8.1 Overview of Microsoft Azure servicesThe web dashboard is implemented mainly on top of the Microsoft Azure services detailed below.
Figure 33. Overview of the main Azure services used
• Azure DPS: to automate board registration to a predefined IoT Hub.• Azure IoT Hub: created to collect sensor data from connected boards when FP-CLD-AZURE1 binaries are
used (azure.microsoft.com/en-us/services/iot-hub/).• Azure Function: to transform real-time sensor data received through IoT Hub and store them in the database
(azure.microsoft.com/en-us/services/functions/).• Azure Cosmos DB: NoSQL database containing data sent by devices in the last 48 hours
(azure.microsoft.com/en-us/services/cosmos-db/).• Azure Web Apps: developed using Azure Web Apps to visualize real-time sensor data and to remotely
control the connected device (azure.microsoft.com/en-us/services/app-service/web/).
2.8.2 Device provisioningThe pre-compiled binary Azure_Sns_DM_BL.bin includes a procedure to automate registration of your device toIoT Hub by contacting DPS (see Section 2.7.3 DICE emulator for robust Internet of Things for details).The MAC address of the Wi-Fi is used to register and identify univocally the device in the IoT Hub and can beread from the serial terminal.After the initialization phase, the application contacts DPS to be registered to the IoT Hub: it receives the deviceID and the URL for the IoT hub from DPS.After these steps the board closes the connection with the DPS and opens a new connection with the IoT hub(see Section 2.7.3 DICE emulator for robust Internet of Things for details).
2.8.3 Usage of web dashboard for sensor data visualizationOnce your board is registered with the IoT Hub, you can use STM32 ODE web dashboard to visualize sensordata and control the device.
2.8.3.1 Add a device to the dashboard
To control and monitor a device using the dashboard, you have to create a device group and add the device to it.
Step 1. Open https://stm32ode-v2.azurewebsites.net.Step 2. Create a new group (or login with an existing one) with group name and password.Step 3. Add your device to the group by clicking the [Add device] button and insert the device ID (MAC
address) and the device custom name.Step 4. Alternatively, copy and paste the URL shown in the serial terminal (or use NFC for Android mobiles) to
directly access the register device.
Figure 34. STM32 ODE IoT web dashboard: create/login group and add device
By clicking the device [Details] button you can monitor the device state, configure and control it.The [Overview] tab contains:• Device custom name: custom name• Device ID: MAC address• State:
– Connection: green if the device is connected to the IoT Hub, red otherwise– Activity: yellow if the device is not sending data for more than the telemetry interval configured, green
otherwise– Application: firmware application state reported by the device
• Location: geographic position associated with the device by the user
The [Control] tab provides two ways of controlling the device:• Direct methods: methods supported by the device are listed and can be invoked by clicking the [Play]
button. If a method needs input parameters, an input form pops up.• Message cloud to device: provides a tool to send messages to the device (mainly for the command feature
offered by previous FP-CLD-AZURE1 firmware versions).
Figure 36. STM32 ODE IoT web dashboard: device details - control tab
The [Configuration] tab allows configuring the device by updating the [Desired Properties] section. The onlyparameter actually interpreted by device is [DesiredTelemetryInterval] which means how often (in seconds)telemetry data are sent by the device. Once edited, the device configuration can be permanently stored byclicking the [Save] button.
From the dashboard you can start the FOTA invoking the related direct method [FirmwareUpdate] as per theprocedure below.
Step 1. Click the play button associated to the [FirmwareUpdate] method.Step 2. From the input form, upload a new firware binary file.Step 3. Select the file just uploaded and start FOTA clicking [Send].
The device starts downloading the binary file from the cloud and, at completion, updates its firmware.
2.8.3.3 Telemetry data visualizationSTM32 ODE web dashboard allows visualization of telemetry data sent by devices to the cloud. To visualize it,click the [Telemetry] tab on the web application right bar, or alternatively copy and paste the URL shown in theserial terminal or use NFC with an Android mobile.
UM2043STM32 ODE web dashboard for FP-CLD-AZURE1
UM2043 - Rev 7 page 34/42
Figure 38. STM32 ODE IoT web dashboard: telemetry visualization
From the device list, you can choose the device and measures to visualize environmental and inertial sensorsembedded in the B-L475E-IOT01A.Each measure selected is mapped in a chart tab, and if you select the same measures for multiple devices, dataare plotted on the same chart for comparison.You can also visualize historic data sent by the devices in the last 1, 3, 6 , 12 hours or incoming real-time data.
2.8.4 Service limitations• Usage of STM32 ODE web dashboard is provided free of charge for evaluation purposes only of FP-CLD-
AZURE1; it does not require user registration.• STM32 ODE web dashboard offers only a limited set of features and functions intended to provide a
quickstart evaluation of STM32 Nucleo, expansion boards, and functionalities available in FP-CLD-AZURE1.The service is provided without warranties of any kind. Any use of the web dashboard in a productionenvironment or for commercial purposes is not recommended or supported; any such use is therefore atproper risk.
• ST may at any time suspend, revoke, or limit the usage of the service.
3.1 Hardware descriptionThis section describes the hardware components needed to connect the Discovery Kit for IoT node to theMicrosoft Azure IoT Hub.
3.1.1 STM32L4 Discovery kit for IoT nodeThe STM32L4 Discovery kit for the IoT node (B-L475E-IOT01A) allows users to develop applications with directconnection to cloud servers. The STM32L4 Discovery kit enables a wide diversity of applications by exploitinglow-power multilink communication (BLE, Sub-GHz), multiway sensing (detection, environmental awareness) andARM® Cortex®-M4 core-based STM32L4 Series features. Arduino™ Uno V3 and PMOD connectivity provideunlimited expansion capabilities with a large choice of specialized add-on boards.The STM32L4 Discovery kit includes an ST-LINK debugger/programmer and comes with the comprehensiveSTM32Cube software libraries together with packaged software samples for a smooth connection to cloudservers.
Figure 39. STM32L4 Discovery kit for IoT node
Information regarding the STM32L4 Discovery kit for the IoT node is available at
3.2 Software requirementsThe following software components are needed to set up a suitable development environment for compiling andrunning the FP-CLD-AZURE1 package:• FP-CLD-AZURE1 software available on www.st.com/stm32ode• Development tool-chain and compiler; the FP-CLD-AZURE1 software supports the three following
environments:– IAR Embedded Workbench for ARM® (IAR-EWARM) toolchain + ST-LINK– RealView Microcontroller Development Kit (MDK-ARM-STM32) toolchain + ST-LINK– System Workbench for STM32 + ST-LINK
• Serial line monitor (e.g., TeraTerm, https://ttssh2.osdn.jp/)• Microsoft Device Explorer tool available on https://github.com/Azure/azure-iot-sdk-csharp/tree/master/tools/
DeviceExplorer
• For using the pre-compiled binaries and web dashboard: Chrome® web browser (http://www.google.com/chrome/)
3.3.1 Hardware setupThe following hardware components are needed:1. One STM32L4 Discovery Kit for IoT node (order code: B-L475E-IOT01A)2. One USB type A to Micro-B USB cable to connect the STM32L4 Discovery Kit to the PC
3.3.2 Software setup
3.3.2.1 Development tool-chains and compilers
Select one of the IDEs in Section 3.2 Software requirements and refer to the system and setup informationprovided by the selected IDE provider. Project files for all of the supported IDEs can be found inside one of thefollowing FP-CLD-AZURE1 package folders, i.e. for IAR Embedded Workbench:• Projects\Multi\Applications\Azure1\EWARM\B-L475E-IOT01
sample application description, Section 2.7.2.2 Use pre-compiled binaries, Section 2.7.2.3Modify and rebuild solution files, Section 2.8.3.1 Overview of the web page sections, Section3.3.1 Hardware setup and Section 3.3.3 System setup guide for STM32 Nucleo and expansionboards;
• added Section 2.7.7 Motor control sample application, Section 2.7.8 IoT Central sample forAzure_Sns_DM application, Section 3.1.5 X-NUCLEO-IHM02A1 expansion board and Section3.1.6 X-NUCLEO-NFC04A1 expansion board;
• removed references to X-NUCLEO-IKS01A1 and X-NUCLEO-NFC01A1 expansion boards.
09-Jan-2019 7 Updated all content to reflect v4.0 firmware version.
STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to STproducts and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. STproducts are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgement.
Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design ofPurchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
ST and the ST logo are trademarks of ST. All other product or service names are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
