DOCSEARCHbyAlgolia
Submit Docs

STM32CubeWB Firmware Package

repository·master·Indexed 43 days ago

https://github.com/stmicroelectronics/stm32cubewb

A monolithic firmware package for STM32WB series microcontrollers, providing drivers, middleware, and software projects. Includes an experimental CMSIS-DSP Python wrapper for testing algorithms using numpy, as well as CMSIS components such as Core, DSP, NN, and RTOS.

Tokens
204.5K
Snippets
146
Records
960
Agent score
52%

What's inside STM32CubeWB

  1. Overview of the Thread OTA Application

    master

    The Thread OTA (Over-The-Air) application demonstrates how to update both the Application firmware and the Coprocessor (Copro) Wireless binary using a Thread network (Client side).

    System Roles

    The application requires two STM32WB55xx boards acting in a Thread network:

    • Leader (Router): Acts as the Thread_Ota_Server. Indicated by Green LED2 ON.
    • Child (End Device): Acts as the Thread_Ota client. Indicated by Red LED3 ON.

    Update Types

    1. Application Update (FW_APP): Updates the main application firmware. After reboot, the device boots at 0x10000 into an OTA-compatible application.
    2. Copro Wireless Update (FW_COPRO_WIRELESS): Updates the wireless coprocessor. After reboot, the device boots into the FUS (Firmware Upgrade Service), which installs the encrypted binary on the Copro side.

  2. Overview of Zigbee OnOff Channels Agility SED Application

    master

    This application demonstrates how to use the OnOff cluster on a Sleepy End Device (SED) acting as a Client within a centralized Zigbee network. It specifically showcases the creation of multiple Zigbee centralized networks using Channel Agility, where each network is assigned a different channel (e.g., Channel 15 for network1 and Channel 20 for network2) to avoid interference.

    Network Roles and Firmware Requirements

    To replicate the multi-network setup, you need different firmware binaries for the Wireless Coprocessor and specific applications for each board role:

    RoleApplicationWireless Coprocessor Binary
    Zigbee Coordinator (ZC)Zigbee_OnOff_ChannelsAgility_ZCstm32wb5x_Zigbee_FFD_fw.bin
    Zigbee Router (ZR)Zigbee_OnOff_ChannelsAgility_ZRstm32wb5x_Zigbee_FFD_fw.bin
    Sleepy End Device (SED)Zigbee_OnOff_ChannelsAgility_SEDstm32wb5x_Zigbee_RFD_fw.bin

    Expected Behavior

    • ZC (Server): When boot is complete, the BLUE_RED LED is ON. Upon receiving a ZbZclOnOffClientToggleReq from an SED or ZR, the LED_RED toggles.
    • SED (Client): Pressing the push button (PushB) sends a toggle request. The LED_RED toggles when a command is successful. The Blue LED stays ON as long as ACKs are received; it turns OFF if an ACK fails (e.g., if the device is moved >5m away due to the -20dBm tx_power setting).
    • ZR (Router/Client): Pressing the push button (PushB) sends a toggle request to the ZC. The LED_RED toggles for each received press.

  3. Overview of BLE_HeartRateThreadX Application

    master

    The BLE_HeartRateThreadX application demonstrates how to implement the BLE SIG Heart Rate profile using the ThreadX OS on STM32WB55xx devices. It is designed to run on the STM32WB series and has been validated on the P-NUCLEO-WB55 board.

    Key features include:

    • BLE Heart Rate profile implementation.
    • Support for ThreadX OS.
    • Low power mode support.
    • Support for 2Mbits PHY.
    • Pairing support via hardware switches.

  4. Overview of the Thread CoAP Data Transfer application

    master

    The Thread_Coap_DataTransfer application is a Proof of Concept demonstrating how to transfer large blocks of data (specifically 5 blocks of 128 bits each) through the CoAP messaging protocol over a Thread network. It utilizes both Multicast and Unicast communication modes to establish connectivity and transfer files between two devices.

    Network Roles and Indicators

    The application requires two STM32WB55xx devices. Upon reset, they automatically assume different roles indicated by onboard LEDs:

    • Leader (Router): Indicated by Green LED2 ON.
    • Child (End Device): Indicated by Red LED3 ON.

    Communication Workflow

    1. Provisioning (Multicast): The Child device uses Multicast addressing in the Mesh-Local scope to probe the Leader's IP address via a CoAP GET request on the "provisioning" resource.
    2. Response: The Leader responds with a CoAP PUT containing the MeshLocal EUI.
    3. Data Transfer (Unicast): Once the IP is known, the Child performs a unicast file transfer using CoAP PUT requests on the "File" resource with Confirmable message type.
    4. Completion: A successful transfer is indicated by the Blue LED lighting up.

  5. Overview of the BLE_Power_Peripheral Application

    master

    The BLE_Power_Peripheral application is a demonstration project designed to show how a BLE application can be created using CubeMX on STM32WB55xx devices.

    Key Features:

    • Dual BLE Services: Includes a BLE_P2P_Server like service (2 characteristics) and a BLE_Heart_Rate like service (3 characteristics).
    • Connectivity: Supports advertising, smartphone connection (via ST BLE Sensor or ST BLE Toolbox), and BLE event management.
    • Hardware Target: Specifically tested on the P-NUCLEO-WB55 board (MB1355C), but can be tailored for other supported devices.
    • Power Management: Configured by default to support low power modes (No traces - No debugger).

  6. Overview of the BLE P2P Router Application

    master

    The BLE_p2pRouteur application demonstrates multipoint BLE communication using an STM32WB55xx device. The router acts as a bridge between a smartphone and up to six remote end devices (P2P Servers).

    Key Capabilities

    • Multipoint Connectivity: Maintains up to seven simultaneous connections (1 slave connection to a smartphone and 6 master connections to end devices).
    • Dual Role: The router device acts as both a Peripheral (GAP) / Server (GATT) for the smartphone and a Central (GAP) / Client (GATT) for the end devices.
    • Automatic Discovery: The Central device automatically scans, connects to, and discovers the P2P Services & Characteristics (specifically the ST-specific Led Button service) of the connected servers.
    • Data Routing: Allows a smartphone to control the blue LED of any connected P2P Server and receive notification events when a button (SW1) is pressed on a Server.

  7. Overview of the Thread RCP Application

    master

    The Thread RCP (Radio Co-Processor) application demonstrates the OpenThread Border Router feature using an STM32WB device. It allows an STM32WB device to act as a radio co-processor in a Thread network, bridging the Thread network to an Ethernet network via a host device.

    Hardware Requirements:

    • An STM32WB Nucleo board.
    • A Raspberry Pi 3B (RPi) to act as the Host and provide the link to the Ethernet network.

  8. Overview of BLE Mesh Model Sensor Demo

    master

    This application implements the BLE Mesh Sensor Model (both Client and Server) as specified by the BLE SIG. It is designed to demonstrate the sensor model using an STM32WB5MM Discovery Kit. The demo allows a Sensor Client to request measured temperature and distance from a Sensor Server over a BLE Mesh network via sensor commands.

    Key features supported by the ST BLE-Mesh library in this implementation include:

    • Relay: Forwards received network PDUs on advertising or GATT bearers (if Proxy is enabled).
    • Proxy: Forwards received network PDUs between GATT and advertising bearers.
    • Friend: Performs duties such as scanning for associated Low Power nodes.
    • Low Power: Reduces energy consumption by allowing nodes to sleep, offloading scanning duties to a Friend node (Friendship concept).

  9. Overview of Zigbee OnOff Client SED Application

    master

    The Zigbee_OnOff_Client_SED application demonstrates how a Sleepy End Device (SED) acts as a Zigbee Client within a centralized network using the OnOff cluster.

    Key Behavior:

    • The Sleepy End Device periodically sends an ZbZclOnOffClientToggleReq command to an OnOff server with a 1-second delay.
    • To achieve ultra-low power consumption (approx. 3uA in IDLE), the application is configured to enter Stop mode 2 when idle.

    Critical Low Power Requirement: To use low power modes with Zigbee on STM32WB, you must use the specific wireless coprocessor binary: stm32wb5x_Zigbee_RFD_fw.bin.

  10. Overview of Zigbee OnOff Channels Agility Application

    master

    This application demonstrates how to use the OnOff cluster on a device acting as a Client with a Router (ZR) role within a centralized Zigbee network. It specifically showcases the creation of multiple Zigbee centralized networks using Channel Agility, where each network is assigned a different channel (default: Channel 15 for network1 and Channel 20 for network2) to avoid interference.

    Device Roles and Firmware Requirements

    Device RoleApplication NameWireless Coprocessor Firmware
    Zigbee Coordinator (ZC)Zigbee_OnOff_ChannelsAgility_ZCstm32wb5x_Zigbee_FFD_fw.bin
    Zigbee Router (ZR)Zigbee_OnOff_ChannelsAgility_ZRstm32wb5x_Zigbee_FFD_fw.bin
    Zigbee End Device (SED)Zigbee_OnOff_ChannelsAgility_SEDstm32wb5x_Zigbee_RFD_fw.bin

    Expected Behavior

    • ZC (Server): When boot is complete, the BLUE_RED LED is ON. When receiving ZbZclOnOffClientToggleReq commands, the LED_RED toggles.
    • ZR (Client/Router): Pressing the push button (PushB) sends an OnOff command to the ZC. The LED_RED toggles once for each received push button press.
    • SED (Client/End Device): Pressing the push button (PushB) sends an OnOff command to the ZC. The LED_RED toggles. The Blue LED stays ON until an ACK failure is detected (e.g., if moved >5m away due to the -20dB tx_power setting).

  11. Overview of Zigbee DevTemp Client/Router Application

    master

    This application demonstrates how to use the Device Temperature cluster in a centralized Zigbee network. It allows a device acting as a Client with a Router role to communicate with a Server node to request temperature data.

    Key Functionality

    • Network Topology: Uses a centralized Zigbee mesh network. One device must act as the Coordinator, while all other devices act as Routers.
    • Communication: The Client sends ZbZclReadReq requests to the Server to retrieve current temperature, minimum temperature experienced, and maximum temperature experienced attributes.
    • User Interaction:
      • Pressing SW1 on the Client triggers a request for temperature attributes.
      • The Client displays the retrieved temperature information on its display.
      • On the Server side, push buttons can be used to simulate temperature changes via ZbZclAttrIntegerWrite (e.g., increasing or decreasing temperature by 2°C).

  12. Overview of Thread FTD Coap Multicast Application

    master

    This application demonstrates how to exchange multicast CoAP messages within a Thread network using two STM32WB55xx boards.

    In a Thread network, nodes function as either a Router (Leader) or an End Device (Child). This application automatically assigns these roles upon reset:

    • Leader (Router): Indicated by Green LED2 ON.
    • Child (End Device): Indicated by Red LED3 ON.

    Interaction Logic:

    • Pressing SW1 Push-Button on one board sends a multicast CoAP command to the resource "light" on the other board.
    • The receiving board toggles its Blue LED1 (ON/OFF) based on the command.
    • This interaction is bidirectional between the two devices.