# STM32WBA-BLE-performance

**Repository Path**: stjinqi/STM32WBA-BLE-performance

## Basic Information

- **Project Name**: STM32WBA-BLE-performance
- **Description**: This application demonstrates the performance of the STM32WBA65 by calculating CoreMark while utilizing Bluetooth LE functionality, with options to modify Bluetooth LE parameters.
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-06-03
- **Last Updated**: 2025-06-03

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# STM32WBA-BLE-Performance

## Overview

This project is based on the `BLE_HeartRateFreeRTOS` example from the **STM32Cube_FW_WBA_V1.6.0** package. It demonstrates the performance of the **STM32WBA6** family, highlighting:

- The low CPU load required to run a Bluetooth LE application.
- The peripheral flexibility of the STM32WBA, enabling many tasks without core intervention.

The application is controlled using three software buttons on the **STM32WBA65 Nucleo board**.

---

## Button Controls

- **B1**: Press to start **CoreMark** computations.
  - Note: CoreMark calculation task priority is just above idle task - any other task preempts CoreMark task and start execution once ready
- **B2**:
  - First press: Start BLE advertising.
  - Subsequent presses: Toggle advertising interval between **fast (20 ms)** and **slow (100 ms)**.
- **B3**: Press to request different BLE connection parameters when connected:
  - Toggles between **7.5 ms** and **50 ms** intervals.
  - Note: The client application may not accept the requested interval and used different value instead.

---

## Application Logging

- **Primary VCP (Virtual COM Port)**: Prints application logs via the onboard **STLink-V3** debugger.
- **Secondary VCP**: Prints application statistics.
  - Display stats using the `performance_visualisation.py` script.
  - Make sure to set the correct COM port in the script.

### Run the Visualization Script

```bash
python performance_visualisation.py
```

---

## GPIO Signalization

The application toggles GPIO pins to indicate active tasks:

| Task Name           | GPIO Pin | Pin Number |
|---------------------|----------|------------|
| COREMARK_TASK        | PE0      | GPIO52     |
| STATISTIC_TASK       | PB11     | GPIO39     |
| RNG_TASK             | PB0      | GPIO44     |
| HRSAPP_MEAS_TASK     | PB14     | GPIO47     |
| HIGH_PRIOR_TASK      | PA7      | GPIO43     |
| Radio-related Tasks  | PB13     | GPIO50     |

*Note: The `Radio_TASK_GPIO_PIN` represents multiple tasks related to radio handling.*

---

## CoreMark Results

Measured using **IAR 9.60.4** with high-speed compiler optimizations:

| Condition                                     | CoreMark Score |
|----------------------------------------------|----------------|
| Without RTOS                                 | 413.9          |
| With RTOS (only CoreMark task)               | 409.8          |
| 100 ms advertising                           | 406.5          |
| 20 ms advertising                            | 396.8          |
| Connected, HR notification, 50 ms interval   | 401.6          |
| Connected, HR notification, 11.25 ms interval| 373.1          |

---

## High Priority Task

The code includes a `USE_HIGH_PRIORITY_TASK` macro (default: `0`). When enabled:

- A new FreeRTOS task `HighPriorityTask` is created.
- It runs with the highest priority and can block other tasks.
- Demonstrates that STM32WBA’s BLE controller can maintain the RF link even under low RF task priority.

**Note**: RF performance/throughput will drop, but for applications without strict throughput requirements, the user experience remains unaffected. The time without RF handling must remain below the **supervision timeout** negotiated with the BLE client.