STM Lab 1 STM32F7 and SensorTile

Task 1 STM32F7

This part of the lab will be based on a new hardware, i.e., STM NUCLEO-F767ZI, which is based on STM32F767ZI MCU (Cortex-M7 core). The development board is STM32 Nucleo-144 type (LQFP144 package) and supports Arduino, ST Zio and morpho connectivity. The schematic is open (based on Altium). The BOM list: [link]

The MCU is STM32F767ZI, The major architecture is shown in the following diagram:

It is based on the high-performance Arm® Cortex®-M7 32-bit RISC core operating at up to 216 MHz frequency

  • Datasheet
  • The Cortex®-M7 core features a floating point unit (FPU) which supports Arm® double-precision
  • All the devices offer three 12-bit ADCs (3×12-bit, 2.4 MSPS ADC: up to 24 channels ), two DACs (2×12-bit D/A converters), a low-power RTC, twelve general-purpose 16-bit timers including two PWM timers for motor control, two general-purpose 32-bit timers, a true random number generator (RNG).
  • Chrom-ART Accelerator™ (DMA2D), graphical hardware accelerator enabling enhanced graphical user interface
  • Hardware JPEG codec
  • LCD-TFT controller supporting up to XGA resolution
  • MIPI® DSI host controller supporting up to 720p 30 Hz resolution (
    8- to 14-bit camera interface up to 54 Mbyte/s)
  • USB 2.0 high-speed/full-speed device/host/OTG controller with dedicated DMA, on-chip full-speed PHY and ULPI
  • 10/100 Ethernet MAC with dedicated DMA: supports IEEE 1588v2 hardware, MII/RMII

Task 1.1 ARM MBED OS Quick Start

One of the features of theSTM NUCLEO-F767ZI is the ARM MBED OS support.

  • Arm Mbed OS is a free, open-source embedded operating system designed specifically for the “things” in the Internet of Things.
  • It includes all the features you need to develop a connected product based on an Arm Cortex-M microcontroller, including security, connectivity, an RTOS, and drivers for sensors and I/O devices.
  • A broad range of connectivity options are available in Mbed OS, supported with software libraries, development hardware, tutorials and examples.
  • With an RTOS core based on the widely used open-source CMSIS-RTOS RTX, Mbed OS supports deterministic, multithreaded real time software execution. The RTOS primatives are always available, allowing drivers and applications to rely on features such as threads, semaphores and mutexes.
  • Mbed supports key MCU families including STM32, Kinetis, LPC, PSoC and nRF52: device support link

Please go to the ARM MBED device link for the STMF767: [link]. This page shows all the features of the NUCLEO-F767ZI and the pinout definitions.

  • In the right side of the page, click “add to Mbed Compiler”
  • You are required to create an ARM Mbed account or login to the existing account. After successful login, you will see ”
    NUCLEO-F767ZI has been added to your account”. Click the “Open Mbed Compiler” button as shown below
  • You will see the main page of the ARM Mbed online compiler, as shown below
  • You can create a new program based on the NUCLEO-F767ZI platform and select one of the Templates (shown below).
  • Select the first first blinky example, you will see your created project. The main.cpp file looks like this. The ARM Mbed code is very simple and highly abstracted. The following code defines the serial port pc, then simply using pc.printf to output message to the terminal. Define the led1 is also very simple (based on DigitalOut), and led1=!=led1 simply toggles the LED.
  • Before you compile the project, make sure you selected the right platform in the right side of the toolbar. If your platform is not
    NUCLEO-F767ZI, you can click the device manager and select
    NUCLEO-F767ZI as shown below (you also can switch to different platforms).
  • To compile the code, simply click the “Compile” button.
  • After compiling done, you will be asked to save one BIN file. In ARM Mbed, downloading the code to the board is very simple. When you connect the device to your PC, it will shown like a flash drive. You just need copy the BIN file to the flash drive, it will automatically download the executable code (BIN) to the board. Here, we simply save the generated BIN file to the NODE_F767ZI flash drive as shown below.
  • After the code has been downloaded, you will see the LD1 blink. You can further connect the board via the terminal. You can open Tera Term or any other terminal software, and select the right COM port and buadrate “9600” to see the message output.

Task 1.2 ARM MBED Examples

You can go to this page to check the ADC/DAC example of the ARM Mbed: [link]. Click “Import into Compiler”. You will see the main.cpp file like this

#include "mbed.h"

AnalogIn in(A0);

#error You cannot use this example as the AnalogOut is not supported on this device.
AnalogOut out(PA_4);

DigitalOut led(LED1);

// Hyperterminal configuration
// 9600 bauds, 8-bit data, no parity

int main()
    printf("\nAnalog loop example\n");
    printf("*** Connect A0 and PA_4 pins together ***\n");
    while(1) {
        for (float out_value = 0.0f; out_value < 1.1f; out_value += 0.1f) {
            // Output value using DAC
            // Read ADC input
            float in_value =;
            // Display difference between two values
            float diff = fabs(out_value - in_value);
            printf("(out:%.4f) - (in:%.4f) = (%.4f) ", out_value, in_value, diff);
            if (diff > 0.05f) {
            } else {
                printf("\033[1A"); // Moves cursor up of 1 line
            led = !led;

The ADC input pin is “A0”, which is PA_3 pin in CN9 connector; the DAC output pin is PA_4 in CN7. The pin definition is in the this page. Using one jumper cable to connect PA_3 pin and PA_4 together, i.e., DAC output to the ADC. After you connect these two pins, you will see the following terminal output

You can go to this link to see the most simple ARM Mbed RTOS example. The main.cpp file looks like this

#include "mbed.h"

void print_char(char c = '*')
    printf("%c", c);

Thread thread;

DigitalOut led1(LED1);

void print_thread()
    while (true) {

int main()
    printf("\n\n*** RTOS basic example ***\n");


    while (true) {
        led1 = !led1;

You can simply use “thread.start(print_thread)” to create a new RTOS thread.

You can check other sample codes in the main page of the board: [link]

Task 1.3 ARM MbedStudio (optional)

ARM also developed one local version of the IDE: ARM MbedStudio. The Mbed Studio supports debug features. However, it is still in beta version. The supported board is very limited.

After you install the ARM MbedStudio (Windows, Linux, Mac version), the main page of the ARM MbedStudio is like this.

You can click File->New Program, select one of the template (e.g., mbed-os-example-blinky)

The main code looks like this

In order to make the ARM MbedStudio to recognize our NUCLEO-F767ZI board, we need to upgrade the ST-LINK firmware. You can download the fireware upgrade software from here: [link]. After you installed the software, you will see this page

You can click “Device Connect” to identify the device, and click “Yes” to upgrade the firmware.

After you upgraded the firmware, the ARM MbedStudio will recognize the NUCLEO-F767ZI board in the Target part automatically.

After the board has been recognized, you will have a new “Run” button after the Build button (as shown below). You can click the “Run” to download the code.

The ARM MbedStudio provides the Debug features, but it requires the pyOCD support [link]. Currently, the debug feature only support the following boards [link]. Our NUCLEO board is not in the list yet.

Task 2 STM32Cube

STM32CubeM7 [link] comprises the STM32CubeF7 MCU Package composed of the STM32Cube™ hardware abstraction layer (HAL) and the low-layer (LL) APIs, plus a consistent set of middleware components (RTOS, USB, FAT file system, Graphics and TCP/IP). TouchGFX graphic software stack is also included in the STM32CubeF7 MCU Package as a part of the STM32Cube™ ecosystem. It also includes STM32CubeMX, a graphical software configuration tool that allows the generation of C initialization code using graphical wizards. 

Task 2.1 STM32CubeF7 Examples

The STM32CubeM7 components are shown in the following figure.

STM32CubeF7 gathers, in a single package, all the generic embedded software components required to develop an application on STM32F7 microcontrollers. In line with the STMCube™ initiative, this set of components is highly portable, not only within the STM32F7 Series but also to other STM32 series.


The package structure of the STM32CubeF7 is shown in

After you downloaded the STM32CubeF7 and extract the package, the projects related to F767 is shown under Projects->STM32F767ZI-Nucleo folder.

The firmware architecture (divided into three levels) is shown in the following figure.

  • The folders inside the STM32CubeF7 called Examples, Examples_LL, and Examples_MIX are in level 0. These examples use respectively HAL drivers, LL drivers and a mix of HAL and LL drivers without any middleware component.
  • The Applications folder is in level 1, they provide typical use cases of each middleware component.
  • The Demonstration folder is in level 2, they implement all the HAL, BSP and middleware components.

Open the IDE for STM32, for example, System Workbench for STM32 ( It has Mac, Linux and Windows version. The download link of the Windows version is [here]. If you do not have Java installed, you should download Java from [here]. The Oracle Java 11/12 installers do not register Java as the default JRE on the system path, you should setup the Java path in Windows environment.

We can import any example projects inside the STM32CubeF7 folder, for example, the GPIO example

The main code looks like the following figure. The drivers are defined as the HAL lay. All APIs start with HAL_, for example, HAL_GPIO_TogglePin.

You can import other Examples in the STM32CubeF7 to check the sample code of different peripherals.

Task 2.2 STM32CubeMX

STM32CubeMX is a graphical tool that allows a very easy configuration of STM32 microcontrollers and microprocessors, as well as the generation of the corresponding initialization C code for the Arm® Cortex®-M core or a partial Linux® Device Tree for Arm® Cortex®-A core), through a step-by-step process.

  • STM32CubeMX main link. Download the STM32CubeMX software
  • STM32CubeMX is available as standalone software running on Windows®, Linux® and macOS® (macOS® is a trademark of Apple Inc. registered in the U.S. and other countries.) operating systems, or through Eclipse plug-in. Inside the download folder, you will see the Mac, Linux and Windows version
  • Install the STM32CubeMX software
  • After the STM32CubeMX has been installed, you can create a new project by either access to MCU selector or Board selector.
  • Click “Access to Board Selector”, and select the NUCLEO-F767ZI board from the list
  • Click start project, click YES for the popup window (initialize in default mode)
  • After you opened the project, you can configure the pinout, clock, and manage the project in the following GUI
  • You can click any pins in the chip diagram and select the function of each pin
  • In addition to select different pin functions and modules, you also can select middleware componets in the left side. For example, you can select FREERTOS in the middleware part
  • We can also configure the timebase source for the FreeRTOS. We can select SYS in System Core, and configure the Timebase Source as TIM2.
  • After the pin and module configuration finished, we can configure the Project Manager. Name the project and location, select the Toolchain as “SW4STM32”. Click save the project, it will ask to download the required fireware (1.24GB).
  • In the Code Generator page (left side bar), we can select “Generate peripheral initialization as a pair of .c/.h files”
  • After all the configuration is done, we can click “Generate the code” button to generate the System Workbench project. Open System Workbench for STM32, we can import our generated project. The source file architecture as shown below
  • Open the freertos.c, add the following code (create a ToggleLedThread) after the default thread definition
  /* add threads, ... */
  osThreadDef(Thread, ToggleLedThread, osPriorityBelowNormal, 0, configMINIMAL_STACK_SIZE);
  osThreadCreate(osThread(Thread), NULL);

Question: please add the missing ToggleLedThread function, and toggle the LED2 or LED3 in every 1 or 2 second.

Task 2.3 STMCubeIDE (optional)

STMicroelectronics’ STM32CubeIDE is a free, all-in-one STM32 development tool offered as part of the STM32Cube software ecosystem.

  • Latest version: 1.0
  • The STM32CubeIDE leverages ST’s 2017 acquisition of embedded-development-tool vendor Atollic.
  • It is offered under industry-standard open license terms and adds dedicated STM32-specific features to simplify and accelerate STM32-based embedded designs.
  • These include the STM32CubeMX tool for configuring the microcontroller and managing the project build.
  • Based on ECLIPSE™/CDT, with support of ECLIPSE™ add-ons, GNU C/C++ for Arm® toolchain and GDB debugger.
  • Support of ST-LINK (STMicroelectronics) and J-Link (SEGGER) debug probes
  • Import project from Atollic® TrueSTUDIO® and AC6 System Workbench for STM32
  • Multi-OS support: Windows®, Linux®, and macOS®
  • Additional advanced debug features including: CPU core, IP register, and memory views; Live variable watch view; System analysis and real-time tracing (SWV); CPU fault analysis tool

Task 3 STM SensorTile

The STEVAL-STLKT01V1 (SensorTile development kit) is a comprehensive development kit designed to support and expand the capabilities of the SensorTile and comes with a set of cradle boards enabling hardware scalability.

  • STLKT01V1: [Link]
  • The SensorTile is a tiny, square-shaped IoT module that packs powerful processing capabilities leveraging an 80 MHz STM32L476JGY microcontroller and Bluetooth low energy connectivity based on BlueNRG-MS network processor as well as a wide spectrum of motion and environmental MEMS sensors, including a digital microphone.
  • To upload new firmware onto the SensorTile, an external SWD debugger (not included in the kit) is needed. It is recommended to use ST-LINK/V2-1 found on any STM32 Nucleo-64 development board.
  • In this lab, we will use our Nucleo-F767ZI board as the external SWD debugger for the SensorTile.

There are three PCB boards inside the development kit

  • SensorTile module (STEVAL-STLCS01V1) with STM32L476JG MCU and other sensors
    • LSM6DSM: The LSM6DSM is a system-in-package featuring a 3D digital accelerometer and a 3D digital gyroscope; SPI & I2C serial interface with main processor data synchronization
    • LSM303AGR: The LSM303AGR is an ultra-low-power high-performance system-in-package featuring a 3D digital linear acceleration sensor and a 3D digital magnetic sensor; SPI / I2C serial interfaces
    • LPS22HB: The LPS22HB is an ultra-compact piezoresistive absolute pressure sensor which functions as a digital output barometer. The device comprises a sensing element and an IC interface which communicates through I2C or SPI from the sensing element to the application.
    • MP34DT05-A: The MP34DT05-A is an ultra-compact, low-power, omnidirectional, digital MEMS microphone built with a capacitive sensing element and an IC interface; PDM output
    • BlueNRG-MS: The BlueNRG-MS is a very low power Bluetooth low energy (BLE) single-mode network processor, compliant with Bluetooth specification v4.2; The Bluetooth Low Energy stack runs on the embedded ARM Cortex-M0 core. The stack is stored on the on-chip non-volatile Flash memory and can be easily upgraded via SPI.
    • BALF-NRG-02D3: This device is an ultra-miniature balun which integrates matching network and harmonics filter
    • LD39115J18R: 150 mA low quiescent current low noise voltage regulator; Input voltage from 1.5 to 5.5 V
    • The functional block diagram is shown below

The hardware core system is shown below

  • SensorTile expansion Cradle board (we will use this one in this lab) as shown below
    • Equipped with 16bit stereo audio DAC (TI PCM1774)
    • USB port, STM32 Nucleo, Arduino UNO R3 and SWD connector
    • with SensorTile plug connector
    • ST2378ETTR – 8-bit dual supply 1.71 to 5.5 V level translator
  • Sensortile Cradle board with SensorTile footprint (solderable) (not use it in this lab) as shown below
    • STBC08PMR – 800 mA standalone linear Li-Ion battery charger
    • HTS221 – capacitive digital sensor for relative humidity and temperature
    • LDK120M-R – 200 mA low quiescent current very low noise LDO
    • STC3115 – Gas gauge IC (battery monitoring)
    • microSD card socket

There are four major software libraries and tools for the STM SensorTile

  • STSW-STLKT01: SensorTile firmware package that supports sensors raw data streaming via USB, data logging on SDCard, audio acquisition and audio streaming
  • STBLESensor: iOS and Android demo Apps
  • BlueST-SDK: BlueST-SDK is a multi-platform library (Android/iOS/Python) that enables easy access to the data exported by a Bluetooth Low Energy (BLE) device implementing the BlueST protocol

Task 3.1 STSW-STLKT01 DataLog

The STSW-STLKT01 firmware package for SensorTile provides sample projects for the development of custom applications [link]

  • Built on STM32Cube software technology, it includes all the low level drivers to manage the on-board devices and system-level interfaces.
  • The package comes with the DataLog_Audio, DataLog, AudioLoop and BLE_SampleApp applications.
    • The DataLog_Audio application allows the user to save the audio captured by the on-board microphone on SD card as a common .wav file.
    • The DataLog application features raw sensor data streaming via USB (Virtual COM Port class) and sensor data storage on an SD card exploiting RTOS features
    • The AudioLoop application sends audio signals acquired by the microphone via I²S and USB interfaces, allowing the user to play the sound on loudspeakers/headphones or record it on an host PC
    • The BLE_SampleApp provides an example of Bluetooth Low Energy configuration that enables SensorTile to stream environmental sensor data; it is compatible with the STBLESensor app available for Android and iOS

Let’s download the software from this [link], you will get the following package. The organization is similar to STM32Cube.

To program the SensorTile board, we first plug the SensorTile module to the
SensorTile expansion Cradle board as shown below

To enable the SWD debug feature, we need to use one external ST-LINK debugger (here we just use our NUCLEO-F767ZI board )

  • Remove the ST-LINK jumpers (two jumpers) in the NUCLEO-F767ZI board. This step will disconnect the ST-LINK part to the STM32F767 target MCU. We will use the ST-LINK part to connect the external MCU, i.e., SensorTile. Do not lost the two jumpers.
  • Connect the ST-LINK port in the NUCLEO-F767ZI board to the SWD connector on the SensorTile cradle extension board. A 5-pin flat cable is provided in the SensorTile Kit package. The pin1 should be aligned together.
  • The following figure shows the connection result
  • Plug the two USB ports to your computer (one for ST-Link in NUCLEO-F767ZI, another is for the SensorTile)
  • Using ST Link utility software (en.stsw-link004) to verify the connected target MCU is the SensorTile (STM32L4) not the STM32F7. (If you have any connection errors, you can lower the SWD frequency from 4MHz to other frequencies).

After the hardware setup is ready, we can open System Workbench to import the sample code in STSW-STLKT01. We first import the DataLog sample code first.

You can build and run the code. After you run the code, you will see some popup windows to show a new USB device. This is because the Datalog code setup the USB device and transfer the sensordata through the USB port.

In Device Manager, you will see two COM ports: 1) COM9 is the ST link port (the USB port that connected to the NUCLEO-F767ZI board); 2) COM19 is the newly created USB serial device in the Datalog code for the SensorTile.

To get the sensor data to the computer, we need to use terminal software (e.g., Tera Term) to connect to the COM10

If your code is running, you will see the sensor data is shown in the terminal. (If your terminal connection is stuck or nothing shows, you can plugin the sensortile USB port again)

You can check the project code of the Datalog example

In side the main.c, you will configure the USB device after the HAL_Init(); Then, two threads are created: GetData_Thread and WriteData_Thread. osKernelStart() starts the FreeRTOS kernel.

Please read the code and answer the following questions:

  • The GetData_Thread created one semaphore in the following code. Which function will release the semaphore and let the GetData_Thread continue?
readDataSem_id = osSemaphoreCreate(osSemaphore(readDataSem), 1);
osSemaphoreWait(readDataSem_id, osWaitForever);
  • The GetData_Thread created one pool and one message in the following code. Which code is used to put the sensor data into the Pool? What’s the usage of the Message? How (which code) can the WriteData_Thread get the sensor data?
sensorPool_id = osPoolCreate(osPool(sensorPool));     
dataQueue_id = osMessageCreate(osMessageQ(dataqueue), NULL);
  • Which code is used to send the sensor data to the USB interface?
  • Why the humidity value is always “0”?
  • MX_X_CUBE_MEMS1_Init function and getSensorsData function in datalog_application.c are used to initialize the sensors and get the sensor value.

Task 3.2 STSW-STLKT01 BLE Sample App

Import the BLE Sample App from the STSW-STLKT01

In side the main.c, we perform the following code to initialize the BLE stack after the HAL_Init() and SystemClock_Config().

/* Initialize the BlueNRG */
  /* Initialize the BlueNRG Custom services */
  /* initialize timers */
  StartTime = HAL_GetTick();

The BLE protocol stack is shown in the follow figure [link]

The host controller interface (HCI) layer provides a standardized interface to enable communication between the host and controller.

  • In BlueNRG, this layer is implemented through the SPI hardware interface.
  • The host can send HCI commands to control the LE controller.
  • The HCI interface and the HCI commands are standardized by the Bluetooth core specification

At the highest level of the core BLE stack, the GAP specifies device roles, modes and procedures for the discovery of devices and services, the management of connection establishment and security.

  • GAP handles the initiation of security features.
  • The BLE GAP defines four roles with specific requirements on the underlying controller: Broadcaster, Observer, Peripheral and Central.

The GATT defines a framework that uses the ATT for the discovery of services, and the exchange of characteristics from one device to another. GATT specifies the structure of profiles. In BLE, all pieces of data that are being used by a profile or service are called “characteristics”. A characteristic is a set of data which includes a value and properties.

  • The ATT protocol allows a device to expose certain pieces of data, known as “attributes”, to another device. The ATT defines the communication between two devices playing the roles of server and client, respectively, on top of a dedicated L2CAP channel. The server maintains a set of attributes. An attribute is a data structure that stores the information managed by the GATT, the protocol that operates on top of the ATT. The client or server role is determined by the GATT, and is independent of the slave or master role.

The BLE protocol stack is used by the applications through its GAP and GATT profiles. The GAP profile is used to initialize the stack and setup the connection with other devices. The GATT profile is a way of specifying the transmission – sending and receiving – of short pieces of data known as ‘attributes’ over a Bluetooth smart link. All current Low Energy application profiles are based on GATT. The GATT profile allows the creation of profiles and services within these application profiles

Here is a depiction of how the data services are setup in a typical GATT server.

Inside the Init_BlueNRG_Stack()

  • function hci_init(HCI_Event_CB, NULL); is used to initialize the HCI.
  • ret = aci_gatt_init(); is used to initialize the GATT server on the slave device. Initialize all the pools and active nodes. Until this command is issued the GATT channel will not process any commands even if the connection is opened. This command has to be given before using any of the GAP features. [link]
  • aci_gap_init_ function is used to register the GAP service with the GATT. The device name characteristic and appearance characteristic are added by default and the handles of these characteristics are returned in the event data. The role parameter can be a bitwise OR of any of the values mentioned below. This API initializes BLE device for a particular role (peripheral, broadcaster, central device etc.). The role is passed as first parameter to this API.

Two services are added inside the Init_BlueNRG_Custom_Services()

  • Add_HWServW2ST_Service
    • Use aci_gatt_add_serv to add a service on the GATT server device. Here service_uuid is the 128-bit private service UUID allocated for the service (primary service). This API returns the service handle in servHandle.
    • aci_gatt_add_char()is used to add the characteristics
  • Add Add_ConfigW2ST_Service
    • Use aci_gatt_add_serv to add a service on the GATT server device.
    • aci_gatt_add_char is used to add the characteristics “ConfigCharHandle”

After initialization, the main loop of the application will blink Led when there is not a client connected. It will then handle BLE event (hci_user_evt_proc) and update the BLE advertise data and make the board connectable (setConnectable).

When SendEnv=1 (periodically setup by the TIM1_CH1 timer), it will call SendEnvironmentalData() function to send environmental data.

  • By checking TargetBoardFeatures, then utilize BSP_ENV_SENSOR_GetValue function to read sensor value.
  • If the BLE connection is there, it will use Term_Update function to send data
    • It will call aci_gatt_update_char_value to update the BLE characteristic value.
  • If the BLE connection is not there, it will use STLBLE_PRINTF to print the data to the USB terminal

Task 3.3 SensorTile FP-SNS-ALLMEMS1 (optional)

FP-SNS-ALLMEMS1 is an STM32 ODE function pack which lets you connect your IoT node to a smartphone via BLE and use a suitable Android™ or iOS™ application, like the BlueMS app, to view real-time environmental sensor data, motion sensor data, digital microphone levels and battery level.

  • The FP-SNS-ALLMEMS1 firmware provides a complete framework to build wearable applications. The STBLESensor application based on the BlueST-SDK protocol allows data streaming and a serial console over BLE controls the configuration parameters for the connected boards.
  • FP-SNS-ALLMEMS1 is the default firmware installed in the SensorTile for out of box experience. All STEVAL-STLKT01V1 is already programmed with FP-SNS-ALLMEMS1 firmware.
  • The package also enables advanced functions such as voice communication over BLE, sound source localization and acoustic beam forming using inputs from multiple microphones, as well as sensor data fusion and accelerometer-based real-time activity recognition, audio data logging and MEMS sensor data logging on SD card

This software creates the following first Bluetooth services:

  • HW characteristics related to MEMS sensor devices
  • SW characteristics:
    • quaternions generated by the MotionFX library in short precision
    • magnetic North direction (e-Compass)
    • recognized activity using the MotionAR algorithm
    • recognized carry position using the MotionCP algorithm
    • recognized gesture using the MotionGR algorithm
    • audio source localization using the AcousticSL algorithm
    • audio beam forming using the AcousticBF algorithm
    • voice over Bluetooth low energy using the BlueVoiceADPCM algorithm
    • SD data logging (audio and MEMS data) using Generic FAT File System middleware

The second service exposes the Console service with:

  • stdin/stdout for bi-directional communication between client and server
  • stderr for a mono-directional channel from the STM32 Nucleo board to an Android/iOS device

The full software architecture is shown in

After you download the software, it contains the following folders (similar to STM32Cube)

Open System workbench for STM32, import the ALLMEMS1 sensortile project

The full code looks like this

You can build and download the code the SensorTile. The SensorTile will be function as the same to the out of box experience.

Task 3.4 SensorTile Bootloader (optional)

We can use the ST-Link Utility to flash the code to the Sensortile board and make Sensortile board run the program every time power is supplied to the board.

Open the ST-Link Utility software, click File->Open Files, navigate to the folder where you have the new bin file compiled from the IDE (System workbench)

After you opened the bin file, you will see the following window. Change the value of the Address field to be 0x08004000 and change the value of the Size to be 0x1000. Click Target-Connect

Click Target->Program to start the download window as shown below. Modify the Start address to be 0x08004000. Click Start, then close the bin file.

Navigate to the Utilities folder->BootLoader->STM32L476RG, open the BootLoaderL4.bin file.

Change the address field to be 0x08000000, click Target->Program. Change the start address to be 0x08000000, click start. Then, you can remove the SWD cable and the SensorTile device will start the code automatically after power on.

Apart from storing code, FP-SNS-ALLMEMS1 uses the FLASH memory for Firmware-Over-The-Air updates. It is divided into the following regions (see figure below):

  • 1. the first region contains a custom boot loader
  • 2. the second region contains the FP-SNS-ALLMEMS1 firmware
  • 3. The third region is used for storing the FOTA before the update

The FP-SNS-ALLMEMS1 cannot not be flashed at the beginning of the flash (address 0x08000000), and is therefore compiled to run from the beginning of the second flash region, at 0x08004000

  • The FP-SNS-ALLMEMS1 cannot not be flashed at the beginning of the flash (address 0x08000000), and is therefore compiled to run from the beginning of the second flash region, at 0x08004000

On any board reset:

  • If there is a FOTA in the third Flash region, the boot loader overwrites the second Flash region (with FPSNS-ALLMEMS1 firmware) and replaces its content with the FOTA and restarts the board.
  • If there is no FOTA, the boot loader jumps to the FP-SNS-ALLMEMS1 firmware
  • To flash modified ALLMEMS1 firmware, simply flash the compiled FP-SNS-ALLMEMS1 firmware to the correct address (0x08004000).

Leave a Reply

Your email address will not be published. Required fields are marked *