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
• Protocol stack (for example, Bluetooth® Low Energy, Zigbee®, or Thread®)
• 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. Protocol stacks

Multiple protocol stacks can interface with the application and the hardware. For instance, 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 five different parts:

EWARM Project organization
	Application Common Docs 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.

EWARM Project View

This section is divided in sub-directories: 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 This section regroups the system-related configurations, interfaces, and some application specific modules (Bluetooth®LE timer, low-power management, etc.). Note: These are specific for each application - Not shared by every application and not necessarily in the same configuration. There are also generic modules, interfaces and startup available. They are shared by multiple applications and can be found in the Common/WPAN directory. Config This is where the user can configure the system modules and adapt the system experience. Configuration impact local modules and generic ones contained in the Common/WPAN directory. Interfaces This folder regroups all the HW relatives files, for example, timer_if.h, stm32_lpm_if.h, etc. Modules Contains system modules sources and headers that are application specific. Generic system module are contained inside the Common/WPAN directory. Information Detailed information on the system modules and features can be found in this wiki page.

2.3. Common

Common/WPAN is a directory that handles all the system modules, hardware interfaces, and startup files that are generic in between all the application.

This aims to limit divergence and heterogeneity among the connectivity application.

EWARM Project View

This section is divided in sub-directories: Interfaces This folder regroups all the HW relatives files, for example, hw_aes.h, hw_pka.h, etc. Modules Contains system modules sources and headers that are generic in between the applications. Application specific system module are contained inside the Application System directory. Startup This is the reset handler file location. Note: The configuration of the up-presented modules are all present in each of your application project under the Application::System::Config directory. Information Detailed information on the system modules and features can be found in this wiki page.

Information

This new architecture has been introduced since the v1.5.0 release and the old one will no longer be supported in the next releases.

Information

CubeMX v6.13 still allow both architecture to be generated but the upcoming versions will, by default, generate project following this architecture.

2.4. 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 HAL examples and LL examples repositories

2.5. 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.6. 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.

3. Old vs New Architecture

Since CubeWBA v1.5.0 release, a new architecture has been introduced to clarify and standardize the connectivity projects.

The new architecture regroups the features and modules shared among all the connectivity projects under one common repository.

The new repository is called Common/WPAN.

Even if all the shared files are present in the Common directory, each project still keeps its own configuration - Module, feature, etc.

This is still present in the System/Config repository.

3.1. Differences

The main and only difference between the old and the new architecture lies in the division of the old system part.

It has been split into two distinct parts:

• Generic part

  • The generic part is located inside the new Common/WPAN repository and is shared with the others projects.

  Application specific part

  • The application specific part is located inside the application repository and is only shared by itself.

Differences between old and new architecture

This new design allows to centralize the impact of application configuration. It is now only taking place inside the system repository.

User does not have to modify anything outside this repository if he needs to customize its user experience.

3.2. How to

Starting from the Cube v1.5.0, all applications come with the brand new Common/WPAN architecture.

However, the user might want to change from one architecture to another. This is achievable by using the CubeMX tool.

3.2.1. Switch architecture

First you need to open your application *.ioc file.

Project repository view

Once CubeMX opens, head up to the COMMON_WPAN tab located inside the Utilities section.

CubeMX view #1

Depending on your situation, you can either select or unselect the Common/WPAN for the project generation.

This will determine whether you select the old or the new architecture.

The next step is to re-generate your application. This is done by pressing the GENERATE CODE button.

When generation is over, your application should now be organized either in old or new architecture manner - The one you requested inside CubeMx.

Important

CubeMX v6.13 will be the last version to handle conversion between old and new architecture.