STM32CubeWBA Software Architecture

Click here for Bluetooth^® Low Energy Overview

1 General software architecture

The user can rely on multiple modules and SW blocks to create an application. The whole framework is called “Application Firmware Framework”. The architecture is designed over a 3-level organization:

• Application firmware
• Bluetooth® LE Stack
• Platform resources

Software architecture

1.1 Application Firmware

This is the user application. It is based on:

• IPs either from ST or from a third party.
• Features developed by ST for short-range protocols, such as Bluetooth® LE profiles, etc.
• Utilities required by the application and the protocol stacks.
• Generic Utilities that provide easy access to basic features such as Low power management, Sequencer, etc.

1.2 Bluetooth® LE Stack

The Bluetooth® LE Stack is the main interface between the application and the hardware for Bluetooth® LE purposes. It is composed of two layers:

Bluetooth® LE Host stack

The Bluetooth® LE Host stack manages all networks and transport protocols that allow the application to communicate with other devices. Provided by ST, it can also be substituted by the user's own Host stack.

Bluetooth® LE Controller

The Bluetooth® LE Controller manages the hardware part, the RF state, and guarantees that the RF protocol is correctly followed. It includes the physical layer, the link layer, and the host controller Interface.

1.3 Platform Resources

The platform resources include all the HALs, BSPs, and drivers that facilitate platform hardware use.

2 Project architecture

2.1 Overview

The project organization differs slightly from the application architecture. This organization is repository based and split in 4 different parts:

EWARM Project organization
	Application Drivers Middleware Utilities

2.2 Application

Application is the core part of the project. It regroups all the main information and actions that define the user application. This section is divided in sub-directories:

EWARM Project View

Core This part is the main entry point of the application. It contains all the setup and entry code such as HW initialization routines, IRQs setup, Scheduler configuration, Tasks registration, etc. Contains the files: main.c, app_entry.c, etc. STM32_WPAN The STM32_WPAN repository regroups the connectivity related files. It is composed of two sub-parts: App Main applicative sources files part. For instance, in HR example, this repository contains the main application file (app_ble.c) and the Bluetooth® LE services implementation. Target This is dedicated to the interface and integration of the libraries and modules present in the middleware. System System-related modules, interfaces, and utilities (PKA, RNG, Advanced Memory manager, USART, RTDebug, etc.) There are four sub-parts in this repository: Config This is where the user can configure the system modules and adapt the system experience. Interfaces This folder regroups all the HW relatives files, for example, timer_if.h, stm32_lpm_if.h, etc. Modules Contains all the systems modules sources and header files. Startup This is the Reset handler file location. Detailed information on the system can be found in this wiki page.

2.3 Drivers

The drivers are divided into four component sets:

The hardware abstraction layer (HAL)

This layer provides the hardware abstraction drivers and the hardware interfacing methods to interact with the upper layers (application, libraries, and stacks). The HAL is composed of:

• The HAL Drivers:

A set of portable abstraction APIs based on high level services built around standalone processes. The HAL drivers are functionalities oriented. For example, the APIs of the Timer peripheral could be split into several categories following the functions offered by the IPs (Basic timer, capture, PWM, etc.).

• Low Layer Drivers:

A set of basic drivers with direct hardware access with no standalone process, this layer can be called either by applications or by the HAL drivers.

• The HAL Core drivers:

A set of internal drivers to provide low level operations to the “complex” peripherals like the USB and Ethernet. They all come with a dedicated source and header files. Some drivers may have an additional file containing extended features. Those files end with "_ex".

The BSP Drivers

This layer contains the high-level board services for the different functionalities offered by the hardware (LED, Push buttons, etc.) and the drivers for the external components mounted on the used boards (IO expander, etc.).

CMSIS Drivers

Cortex Microcontroller Software Interface Standard (CMSIS) drivers that provide a single standard across all Cortex-Mx processor series vendors. It enables code re-use and code sharing across software projects.

Information

Examples using the HAL APIs and the Low Layer drivers can be found in the basic peripheral examples repository

2.4 Middleware

Libraries and protocol-based components (Bluetooth® LE stack, etc.). This directory contains Bluetooth® LE services management, system commands, etc.
Horizontal interactions between the components of this layer must be done directly by calling the features APIs while the vertical interaction with the low-level drivers must be done through specific callbacks and static macros implemented in the library interface.

2.5 Utilities

Miscellaneous software utilities that provide additional system and media resources services like sequencer tools box, timeserver, low power manager, several trace utilities and standard library services like memory, string, timer, and math services.
These utilities are not specific to one platform but available to a multitude of STM32 families.