How it Works
Schneider Electric
Loading...
ATV610
User Manual
160 pgs3.87 Mb0
Table of contents
Loading...

Schneider Electric ATV610 User Manual

Introduction
AN5289
Application note
Building wireless applications with
STM32WB Series microcontrollers
To fully benefit from the information in this document and to develop an application, the user must be familiar with STM32 microcontrollers, BLE technology, 802.15.4 OpenThread protocol, Zigbee such as low power management and task sequencing.
®
Low Energy (BLE) or 802.15.4 applications based on STM32WB Series
®
protocol and 802.15.4 MAC layer, and has to understand system services
April 2021 AN5289 Rev 5 1/160
www.st.com
1
Contents AN5289
Contents
1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 List of acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Software overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Supported stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 BLE application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Building a BLE application on top of the HCI layer interface . . . . . . . . . . 15
3.4 Thread application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 MAC 802_15_4 application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 BLE and Thread application in concurrency . . . . . . . . . . . . . . . . . . . . . . . 16
4 STM32WB software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Main principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Shared peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.3 Detailed interface and behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Timer server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.3 Detailed interface and behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 Low power manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7 Flash memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7.1 CPU2 timing protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7.2 CPU1 timing protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7.3 Conflict between RF activity and Flash memory management . . . . . . . 37
4.8 Debug information from CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8.1 GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2/160 AN5289 Rev 5
AN5289 Contents
4.8.2 SRAM2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9 FreeRTOS low power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.10 Device information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11 ECCD error management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 System initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1 General concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 CPU2 startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 Step by step design of a BLE application . . . . . . . . . . . . . . . . . . . . . . . 46
6.1 Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Advertising phase (GAP peripheral) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3 Discoverable and connectible phase (GAP central) . . . . . . . . . . . . . . . . . 47
6.4 Services and characteristic configuration (GATT server) . . . . . . . . . . . . . 48
6.5 Service and characteristic discovery (GATT client) . . . . . . . . . . . . . . . . . 49
6.6 Security (pairing and bonding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.6.1 Security modes and level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6.2 Security commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6.3 Security information commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.7 Privacy feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.8 How to use the 2 Mbps feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.9 How to update connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.10 Event and error code description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7 BT-SIG and proprietary GATT-based BLE application . . . . . . . . . . . . . 56
7.1 Transparent mode - Direct test mode (DTM) . . . . . . . . . . . . . . . . . . . . . . 56
7.1.1 Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.1.2 Transparent mode application principle . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.4 RF certification - Application implementation . . . . . . . . . . . . . . . . . . . . . 59
7.2 Heart rate sensor application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.2.1 How to use STM32WB heart rate sensor application . . . . . . . . . . . . . . 60
7.2.2 STM32WB heart rate sensor application - Middleware application . . . . 61
7.3 STMicroelectronics proprietary advertising . . . . . . . . . . . . . . . . . . . . . . . 65
7.4 Proprietary P2P application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
AN5289 Rev 5 3/160
6
Contents AN5289
7.4.1 P2P server specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.4.2 How to use the P2P server application . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.4.3 P2P server application - Middleware application . . . . . . . . . . . . . . . . . . 70
7.4.4 P2P client application - Middleware application . . . . . . . . . . . . . . . . . . . 73
7.5 FUOTA application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.5.1 CPU1 user Flash memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.5.2 BLE FUOTA application startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.5.3 BLE FUOTA services and characteristics specification . . . . . . . . . . . . . 80
7.5.4 Flow description example to upload new CPU1 application binary . . . . 81
7.5.5 Application example with smart phone . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.5.6 How to use the reboot request characteristics . . . . . . . . . . . . . . . . . . . . 86
7.5.7 Power failure recovery mechanism for CPU1 application . . . . . . . . . . . 88
7.6 Application tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.6.1 How to set Bluetooth device address . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.6.2 How to add a task to the sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6.3 How to use the timer server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.6.4 How to start the BLE stack - SHCI_C2_BLE_Init() . . . . . . . . . . . . . . . . 91
7.6.5 How to maximize data throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.6.6 How to add a custom BLE service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8 Building a BLE application on top of the HCI layer interface . . . . . . . 98
9 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.2 How to start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.3 Thread configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.4 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.5 Inter core communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.6 OpenThread API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.7 Usage of the OpenThread APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.7.1 OpenThread instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.7.2 OpenThread call back management . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.8 System commands for Thread applications . . . . . . . . . . . . . . . . . . . . . . 104
9.8.1 Non-volatile Thread data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.8.2 Low-power support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4/160 AN5289 Rev 5
AN5289 Contents
10 Step by step design of an OpenThread application . . . . . . . . . . . . . . 107
10.1 Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.2 Set-up the Thread network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.3 CoAP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.3.1 Creating an otCoapResource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.3.2 Sending a CoAP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.3.3 Receiving a CoAP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.4 Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.5 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.6 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
11 STM32WB OpenThread application . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
11.1 Thread_Cli_Cmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
11.2 Thread_Coap_DataTransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
11.3 Thread_Coap_Generic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
11.4 Thread_Coap_Multiboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
11.5 Thread_Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
11.6 Thread_FTD_Coap_Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
11.7 Thread_SED_Coap_Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
11.8 Thread FUOTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
11.8.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
11.8.2 Memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
11.8.3 Thread FUOTA protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.8.4 FUOTA application startup procedure . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.8.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
12 MAC IEEE Std 802.15.4-2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
12.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
12.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
12.4 How to start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
12.4.1 Board configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
12.4.2 MAC radio protocol processor CPU2 firmware . . . . . . . . . . . . . . . . . . 122
12.4.3 MAC application processor firmware . . . . . . . . . . . . . . . . . . . . . . . . . . 122
12.4.4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
AN5289 Rev 5 5/160
6
Contents AN5289
12.4.5 MAC IEEE Std 802.15.4-2011 system . . . . . . . . . . . . . . . . . . . . . . . . . 124
12.4.6 Integration recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
13 Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
13.1 Detailed flow of the device initialization . . . . . . . . . . . . . . . . . . . . . . . . . 127
13.2 Mailbox interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13.2.1 Interface API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.2.2 Detailed interface behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.3 Mailbox interface - Extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.3.1 Interface API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.3.2 Detailed interface and behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.4 ACI interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
13.4.1 Detailed interface and behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
13.5 STM32WB system commands and events . . . . . . . . . . . . . . . . . . . . . . 147
13.5.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
13.5.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.6 BLE - Set 2 Mbps link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.7 BLE - Connection update procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.8 BLE - Link layer data packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.9 Thread overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.9.2 Main characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
13.9.3 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
13.9.4 Mesh topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
13.9.5 Thread configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
14 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
15 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6/160 AN5289 Rev 5
AN5289 List of tables
List of tables
Table 1. Stacks supported by STM32WB Series microcontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 2. Semaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 3. Interface functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 4. Interface functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 5. Interface functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 6. Advertising phase API description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 7. GAP central APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 8. GATT client APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 9. Security commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 10. Security information commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 11. 2 Mbps feature commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 12. Proprietary connection data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 13. Direct test mode functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 14. Heart rate service functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Table 15. HR sensor application control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 16. AD structure according to the Bluetooth 5 Core specification Vol. 3 part C . . . . . . . . . . . . 66
Table 17. STM32WB manufacturer specific data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 18. Group B features - Bit mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 19. Device ID Enum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 20. P2P service and characteristic UUIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table 21. P2P specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table 22. P2P service functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 23. FUOTA service and characteristics UUID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Table 24. Base address characteristics specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 25. File upload confirmation reboot Request characteristics specification . . . . . . . . . . . . . . . . 81
Table 26. Raw data characteristics specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 27. Reboot request characteristics specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 28. MO firmwares available for Thread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 29. Files for Thread configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Table 30. Interface APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Table 31. Interface APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Table 32. BLE transport layer interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Table 33. System interface commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Table 34. User system events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Table 35. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
AN5289 Rev 5 7/160
7
List of figures AN5289
List of figures
Figure 1. Protocols supported by STM32WB Series microcontrollers . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 2. STM32WB Series microcontrollers BLE HCI layer model . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 3. BLE application and wireless firmware architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 4. Memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 5. Timing for entering/exiting Stop mode on CPU1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 6. Algorithm to enter Stop mode on CPU1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 7. Algorithm to exit Stop mode on CPU1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 8. Algorithm to use RNG on CPU1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 9. Algorithm to use USB on CPU1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 10. Algorithm to write/erase data in the Flash memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 11. CPU1 and Flash memory operation versus PESD bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 12. Format of version and memory information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 13. ECC management in NMI interrupt handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 14. System initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 15. GATT-based BLE application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 16. Transparent mode with P-NUCLEO-WB55 board and ST-LINK VCP . . . . . . . . . . . . . . . . 58
Figure 17. Transparent mode with P-NUCLEO-WB55 board and level shifter . . . . . . . . . . . . . . . . . . 59
Figure 18. Simple setup with BLE RF tester and P-NUCLEO board . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 19. Heart rate profile structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 20. Simple setup with BLE RF tester and P-NUCLEO board . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 21. Smart phone - ST BLE sensor with heart rate application . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 22. Heart rate project - Interaction between middleware and user application . . . . . . . . . . . . . 65
Figure 23. P2P server to client demonstration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 24. P2P server to ST BLE sensor smart phone application . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 25. P2P server/client communication sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 26. P2P server connected to ST BLE sensor smart phone application . . . . . . . . . . . . . . . . . . 70
Figure 27. P2P server software communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 28. P2P client software communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 29. FUOTA memory mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 30. FUOTA startup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 31. FUOTA process with heart rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 32. P2P server - Application firmware selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 33. P2P server - Application firmware update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 34. Heart rate sensor notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 35. User option bytes setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 36. Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 37. OpenThread functions calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 38. OpenThread callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 39. OpenThread stack API directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 40. OpenThread callback management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 41. Storage on non-volatile data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 42. Configurable CLI UART (LPUART or USART) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 43. Traces for Thread applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 44. Thread FUOTA network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Figure 45. OTA server (Thread_Ota_Server) Flash memory mapping . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 46. FUOTA client Flash memory mapping initial state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 47. FUOTA server Flash memory mapping after CPU1 binary transfer . . . . . . . . . . . . . . . . . 115
Figure 48. FUOTA server Flash memory mapping after CPU2 binary transfer . . . . . . . . . . . . . . . . . 115
8/160 AN5289 Rev 5
AN5289 List of figures
Figure 49. Thread FUOTA protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Figure 50. FUOTA startup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 51. Update procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 52. MAC 802.15.4 software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Figure 53. MAC API dedicated to application core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 54. Option bytes configuration for MAC 802.15.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 55. MAC 802.15.4 simple application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 56. MAC 802.15.4 applications - Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure 57. Coordinator start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 58. Node start, requesting association, and data send. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 59. Coordinator receiving association request and data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 60. MAC 802.15.4 layer abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 61. Traces on MAC 802.15.4 application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure 62. System initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 63. System ready event notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 64. BLE initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 65. Transport layer initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 66. BLE channel initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 67. BLE command sent by the mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 68. ACL data sent by the mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 69. System command sent by the mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figure 70. BLE and system user event received by the mailbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figure 71. System transport layer initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Figure 72. System command sent by the system transport layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Figure 73. System user event reception flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Figure 74. shci_resume_flow() usage example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Figure 75. BLE transport layer initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Figure 76. ACI command flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Figure 77. BLE user event receive flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Figure 78. hci_resume_flow() usage example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Figure 79. 2 Mbps set-up flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 80. Master initiates the connection update with HCI command . . . . . . . . . . . . . . . . . . . . . . . 151
Figure 81. Slave initiates the connection update with L2CAP command. . . . . . . . . . . . . . . . . . . . . . 151
Figure 82. Data packet breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 83. Application GATT data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 84. Thread protocol letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Figure 85. 6LoWPAN packet fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Figure 86. Thread network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Figure 87. Link with the external world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Figure 88. Thread device roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
AN5289 Rev 5 9/160
9
References AN5289

1 References

[1] UM2550
[2] RM0434
[3] AN5270
[4] UM2442
[5] UM2288
[6] AN5185
[7] Bluetooth
(1)
(1)
(1)
(1)
(1)
(1)
®
specification
[8] MAC IEEE Std
802.15.4-2011
[9] Thread
specification
[10] AN5506
1. Available on www.st.com.
(1)
Getting started with STM32CubeWB for STM32WB Series
Multiprotocol wireless 32-bit MCU Arm®-based Cortex®-M4 with FPU, Bluetooth
®
Low-Energy and 802.15.4 radio solution
STM32WBx5 Bluetooth® Low Energy (BLE) wireless interface
Description of STM32WB HAL and low-layer drivers
STM32CubeMonitor-RF software tool for wireless performance measurements
ST firmware upgrade services for STM32WB Series
Bluetooth Core Specification (v4.0, v4.1, v4.2, v5.0)
Specification of the 802_15_4 MAC standard
Thread specification V1.1 (Thread Group)
Getting started with Zigbee® on STM32WB Series
10/160 AN5289 Rev 5
AN5289 List of acronyms and abbreviations

2 List of acronyms and abbreviations

ACI Application command interface
ATT Attribute protocol
BLE Bluetooth
CLI Command line interface
CoAP Constrained application protocol
CPU1 Cortex
CPU2 Cortex
D2D Device to device
DUT Device under test
FUOTA Firmware update over the air
FUS Firmware upgrade service
GAP Generic access profile
®
Low Energy
®
-M4 core
®
-M0+ core
GATT Generic attribute profile
HCI Host controller interface
L2CAP Logical link control adaptation layer protocol
LTK Long-term key
OTA Over the air
PDU Protocol data unit
P2P Peer to peer
RFU Reserved for future use
SIG Special interest group
SM Security manager
UUID Universally unique identifier
AN5289 Rev 5 11/160
159
Software overview AN5289

3 Software overview

3.1 Supported stacks

The STM32WB Series microcontrollers are based on Arm
Select CPU2 firmware to load based on the target application.
®(a)
cores.
The STM32WB Series microcontroller ecosystem sup controlled by the application through specific in
ports different stacks (see Table 1),
terfaces, as shown in Figure 1.
As shown in Figure 2, CPU2 may provide a BT HCI standard interface and a different BLE stack can run on CPU1.
BLE
Thread
BLE and Thread
BLE and MAC 802_15_4 stm32wb5x_BLE_Mac_802_15_4_fw.bin
BLE and Zigbee

Table 1. Stacks supported by STM32WB Series microcontrollers

Stacks supported Associated firmware
stm32wb5x_BLE_HCI_AdvScan_fw.bin stm32wb5x_BLE_HCILayer_fw.bin stm32wb5x_BLE_LLD_fw.bin stm32wb5x_BLE_Stack_full_fw.bin stm32wb5x_BLE_Stack_light_fw.bin
stm32wb5x_Thread_FTD_fw.bin stm32wb5x_Thread_MTD_fw.bin
stm32wb5x_BLE_Thread_dynamic_fw.bin stm32wb5x_BLE_Thread_static_fw.bin
stm32wb5x_BLE_Zigbee_FFD_dynamic_fw.bin stm32wb5x_BLE_Zigbee_FFD_static_fw.bin stm32wb5x_BLE_Zigbee_RFD_dynamic_fw.bin stm32wb5x_BLE_Zigbee_RFD_static_fw.bin stm32wb5x_Zigbee_FFD_fw.bin stm32wb5x_Zigbee_RFD_fw.bin
MAC 802_15_4
a. Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
12/160 AN5289 Rev 5
stm32wb5x_Mac_802_15_4_fw.bin stm32wb5x_Phy_802_15_4_fw.bin
AN5289 Software overview
MS52414V2
CPU2
802.15.4 radio
M0 firmware
CPU1
ACI interface
Profiles Services
Application
OpenThread stack
UDP + TLS
COAP
BLE radio
BLE stack
Link layer
L2CAP
802.15.4 MACOT 802.15.4 MACBT MAC
HostCtl interface
Routing
SMP
GATT, GAP
ATT
IPVS
6LowPan
Thread
interface
802.15.4 MAC interface
Infrastructure
Zigbee
interface

Figure 1. Protocols supported by STM32WB Series microcontrollers

AN5289 Rev 5 13/160
159
Software overview AN5289
MS52413V1
CPU2
BLE radio
M0 firmware
CPU1
BLE Host stack
HostCtl interface
L2CAP
GATT, GAP
Application
Profiles Services
SMP ATT
HCL layer
BT MAC
Link layer
HostCtl interface

Figure 2. STM32WB Series microcontrollers BLE HCI layer model

3.2 BLE application

The STM32WB architecture separates the BLE profiles and application, running on the application CPU1, from the real-time aspects residing in the BLE peripheral.
The BLE peripheral incorporates a CPU2 processor containing the stack handling the link layer up to the GAP and the GAP layers. It also incorporates the physical 2.4 GHz radio.
The application CPU1 collects and computes the data to be transferred to the BLE.
CPU2 contains the LE controller and the LE host needed to manage all real time link layer and radio PHY interaction which includes:
Low power manager to control Low-power mode
14/160 AN5289 Rev 5
Debug trace to output information about activities
Mailbox / IPCC to interface the BLE stack (LL, GAP, GATT)
AN5289 Software overview
CPU1
User code
MS51765V1
SRAM2 IPCC
ACI - HCI
Profiles Services
Application
CPU2
BLE stack
Radio PHY
GAP GATT
SMP ATT
Link layer DTM
L2CAP
HCI

Figure 3. BLE application and wireless firmware architecture

3.3 Building a BLE application on top of the HCI layer interface

CPU2 may be used as a BLE HCI layer co-processor. In that case, the user either implements its own HCI application or uses an existing open source BLE host stack.
Most BLE host stacks use a UART interface to communicate with a BLE HCI co-processor. The equivalent physical layer on STM32WB Series microcontroller is the mailbox, as described in
The mailbox provides an interface for both the BLE channel and the System channel. The BLE host stack is responsible for building the command buffer to be sent over the BLE channel on the mailbox and must provide an interface to report events received over the mailbox. In addition to the BLE host stack adaptation over the mailbox, the user must notify the mailbox driver when an asynchronous packet can be released.
The System channel is not handled by a BLE host stack. The user has to implement a custom transport layer to build the system command buffer to be sent to the mailbox driver and to manage the event received from the mailbox (including the notification to release an asynchronous buffer to the mailbox driver), or it may use the mailbox extended driver (as described in
Section 13.2: Mailbox interface.
Section 13.3: Mailbox interface - Extended) that provides an interface on top of
AN5289 Rev 5 15/160
159
Software overview AN5289
the transport layer responsible for building the system command buffer and to manage the system asynchronous event.
The BLE_TransparentMode project may be used as an example to build an application on top of a BLE HCI layer co-processor using the mailbox as described in
Thread_Coap_DataTransfer.
Section 11.2:

3.4 Thread application

The OpenThread stack runs on CPU2 core and exports a set of APIs on CPU1 side in order to build a complete Thread application. Three CPU2 firmwares support the Thread protocol:
sm32wb5x_Thread_FTD_fw: In this case, the device supports all Thread roles except
the border router (e.g. Leader, Router, End device, Sleepy end device).
stm32wb5x_Thread_MTD_fw: In this case, the device can act only as an end device
or sleepy end device). This configuration saves on memory space compared to the FTD one.
stm32wb5x_BLE_Thread_fw: In this case, the device supports both Thread (FTD)
and BLE in static concurrent mode (refer to Section 3.6 for more details).

3.5 MAC 802_15_4 application

When downloading the STM32wb5x_Mac_802_15_4_fw CPU2 firmware, CPU1 can access directly the 802_15_4 MAC layer and build its own application on top of it.

3.6 BLE and Thread application in concurrency

The STM32WB Series microcontrollers supports a “static concurrent mode” (also named “switched mode”).
Both stacks (BLE and Thread) are embedded in the stm32wb5x_BLE_Thread_fw CPU2 firmware that is available from www.st.com. Switch from one protocol to the other is done through a system application command. In this mode, the system disables the operational protocol before activating the other one. The STM32WB device switches from BLE to Thread after completely stopping the BLE stack, and vice versa. These transitions can take several seconds, as the network needs to be reattached each time.
16/160 AN5289 Rev 5
AN5289 STM32WB software architecture

4 STM32WB software architecture

4.1 Main principles

All the code running on CPU2 is delivered as an encrypted binary
Black box for customer perspective
All the code running on CPU1 is delivered as source code
Communication between CPUs is done via “mailbox”
The standard STM32Cube delivery package includes STM32WB resources such as:
HAL/LL to access the hardware registers
BSP
Middleware (such as FreeRTOS, USB devices).
In addition, the following application provide efficient system integration:
A sequencer to execute the tasks in background and enter Low-power mode when
there is no activity
A timer server to provide virtual timers running on RTC (in Stop and Standby modes) to
the application.
AN5289 Rev 5 17/160
159
STM32WB software architecture AN5289
MS51862V2
Secure
Free but not available
in default linker file
Available in linker file
SRAM2A
_BASE
End of
User app
SRAM2A
_END_ADDR
SBRSA
SRAM2a
Secure
Free but not available
in default linker file
SRAM2B
_BASE
SRAM2B
_END_ADDR
SNBRSA
SRAM2b
Secure
Free but not available
in default linker file
Available in linker file
FLASH_BASE
End of
User app
FLASH
_END_ADDR
SFSA
Flash
Available in linker file
Not available in
default linker file
Reserved for BLE
OTA application
SRAM1_BASE
SRAM1
_END_ADDR
SRAM1
SRAM1_BASE
+ 4

4.2 Memory mapping

Figure 4. Memory mapping

The Flash, SRAM2a and SRAM2b memories contain a secure section, which cannot be read nor written by CPU1. The secure start address for each memory can be read from the option byte, indicated in blue in
SFSA for the Flash memory
SBRSA for the SRAM2a (retained in Standby)
SNBRSA for the SRAM2b.
Figure 4:
These option bytes are only written by the FUS running on CPU2. This is done on each CPU2 update installed by the FUS.
The user application must take into account that the available memory may vary between different versions of the RF stack. The available space for the user application can be obtained from the release notes for STM32WB coprocessor wireless binaries. The install address for the RF stack is also the boundary address for the user Flash memory area.
18/160 AN5289 Rev 5
AN5289 STM32WB software architecture
Ensure that some margin is included in CPU2 domain to support updates during the product lifetime.
The boundary granularity is 4 Kbytes for the Flash memory and 1 Kbyte for both SRAM2a and SRAM2b.
The linker file is identical to all delivered BLE/Thread applications (except for BLE_Thread_Static, BLE_HeartRate_ota and BLE_p2pServer_ota). The available memories are chosen to fit all provided applications. For applications like BLE, where CPU2 memory requirements are smaller, it is possible to update the linker file to allocate more memory to the application.
To optimize the available memory for a dedicated application, the linker file has to be updated inline with the following guidelines:
Flash memory: the end of available memory address can be moved up to the SFSA
address. When a CPU2 update is required, there must be enough free memory just below the secure memory to upload a new encrypted CPU2 FW update. The size of the memory required depends on CPU2 FW to be updated (BLE, Thread or concurrent BLE/Thread), see [1].
SRAM1: the first unavailable 32 bits in the linker file are only required for the BLE_OTA
application. For all other applications, the start address can be moved from SRAM1_BASE + 4 to SRAM1_BASE.
SRAM2a: the end of available memory address can be moved up to the SBRSA
address. When CPU2 update support required, there must be some free sectors just below the secure memory to support new CPU2 FW updates requiring more sectors to be secure.
SRAM2b: The SRAM2b is not part of the linker file because it is all secure for any FW
CPU2 supporting the Thread protocol. For BLE only applications, the linker file may be updated with a new section to map RW data into the SRAM2B from SRAM2B_BASE up to the SNBRSA address. When CPU2 update support required, there must be some free sectors just below the secure memory to support new CPU2 FW updates requiring more sectors to be secure.
STOP2 is the deepest low power mode supported when RF is active. When the user application has to enter Standby mode, it must first stop all RF activities, and fully re-initialize CPU2 when coming out of Standby mode. The user application may use the full non secure SRAM2a to store its own content (that needs to be retained in Standby mode).

4.3 Shared peripherals

All peripherals concurrently accessible by both CPUs are protected by hardware semaphores. Before accessing these peripherals, the associated semaphore must first be taken, and released afterwards.
Semaphore Purpose
Sem0 RNG - All registers
Sem1 PKA - All registers
Sem2 FLASH - All registers

Table 2. Semaphores

AN5289 Rev 5 19/160
159
STM32WB software architecture AN5289
Table 2. Semaphores (continued)
Semaphore Purpose
RCC_CR
Sem3
Sem4 Clock control mechanism for the Stop mode implementation.
Sem5
Sem6 Used by CPU1 to prevent CPU2 from writing/erasing data in Flash memory.
Sem7 Used by CPU2 to prevent CPU1 from writing/erasing data in Flash memory.
RCC_EXTCFGR RCC_CFGR RCC_SMPSCR
RCC_CRRCR RCC_CCIPR
Sem8
Sem9
Ensures that CPU2 does not update the Thread persistent data in SRAM2 when CPU1 is reading them.
Ensures that CPU2 does not update the BLE persistent data in SRAM2 when CPU1 is reading them.
If the application needs to use semaphores for inter task control, it is recommended to start using Sem31 downwards to be compatible with future wireless firmware updates on CPU1, where new features may be added requiring additional semaphores.
Sem0 is used to share the RNG IP between the two CPUs. The semaphore is taken by the CPU2 for a time interval depending upon the required RNG number to be generated and upon the RNG source clock speed. To relax the latency to get RNG numbers, it is recommended to generate at startup a pool of RNG numbers and fill the pool in a low priority task when some numbers are retrieved by the application to keep it full. The usage of Sem0 is shown in
Figure 8.
Sem 0 can be used in the USB use case too. When the USB is not used anymore and needs to be switched off by the application, Sem 0 must be taken before switching off the CLK48 clock. This is required because USB and RNG share the same clock, and CPU2 could use RNG at the same time when CPU1 needs to switch off the USB (see
Figure 9).
Sem1 is used to share the PKA IP between the two CPUs.
Sem2 is used to share the FLASH IP between the two CPUs. The semaphore is taken by
the CPU2 for a time interval depending upon the number of data to be written in the Flash memory and upon the number of sectors to erase. BLE stack writes to Flash memory the pairing information (when bonding is enabled) and the GATT attribute cache.
Sem3 is used for the low power management. It must not be locked for more than 500 µs by the CPU1 when there is BLE RF activity. The algorithm is detailed in
Sem4 is used to handle race condition on the switch of the system clock when a CPU exits low power mode while the other one enter low power mode. The algorithm is detailed in
Figure 6 and Figure 7.
Sem3 and Sem4 are used in the examples to enter/exit Stop mode.
The user must ensure that the algorithms shown in Figure 6 and Figure 7 are executed before and after wake-up from Stop mode. These routines (see Figure 5) are usually implemented inside the IDLE task of sequencer or RTOS. The implementation takes advantage of the fact that when WFI is called from critical section, the MCU wakes up upon
20/160 AN5289 Rev 5
Figure 6 and Figure 7.
AN5289 STM32WB software architecture
MS53131V1
Thread
PWR_Enter StopMode()
zzz
PWR_Exit
StopMode()
ISR Thread
IRQx
Enter
critical section
Exit
critical section
WFI
Interrupt
exit
interrupt request, but instead of executing ISR it continues to execute the next instruction after WFI. Only after exiting the critical section the ISR is executed.
PRIMASK = 1; // Mask all interrupts (enter critical section) PWR_EnterStopMode()
WFI
PWR_ExitStopMode()
PRIMASK = 0; // Unmask all interrupts (exit critical section)

Figure 5. Timing for entering/exiting Stop mode on CPU1

AN5289 Rev 5 21/160
159
STM32WB software architecture AN5289
MS53122V1
Yes
No
Enter
ENTER_CRITICAL_SECTION
EXIT_CRITICAL_SECTION
Exit
Poll Sem3 until granted
Get Sem4
Sem4 granted ?
C2DS = set ?
Release Sem4
Release Sem3
Set HSION
Wait for HSIRDY
Set SW to HSI
Wait for SWS to report HSI
Set SMPSSEL to HSI
Yes
No
If Sem4 is busy CPU2 has not switched the clock to HSI. It is either in Stop mode, or polling Sem3 to exit Stop mode (in this case, the clock is switched to HSI and switched back to another clock by the CPU2)
CPU2 is either in Run mode on a suitable clock, or polling Sem3 to exit Stop mode
CPU2 is either in Stop mode, or polling Sem3 to exit Stop mode (in this case, the clock is switched to HSI and switched back to another clock by the CPU2)
Enter CStop

Figure 6. Algorithm to enter Stop mode on CPU1

22/160 AN5289 Rev 5
AN5289 STM32WB software architecture
MS53123V1
Enter
ENTER_CRITICAL_SECTION
EXIT_CRITICAL_SECTION
Exit
Poll Sem3 until granted
SWS = HSI ?
Release Sem3
Clock configuration
CPU1 must configure all clocks,
depending on the use case (it
must commit CPU2 at 32 MHz)
Yes
No
Only if HSE is suitable for CPU1 use case.
Release Sem4
Polling time is short, can be kept in the critical section.

Figure 7. Algorithm to exit Stop mode on CPU1

Sem5 is used to control the RNG/USB CLK48 source clock. The CPU2 updates or switches
off the clock only when the RNG IP (Sem0) is used.
To avoid a race condition with the CPU2, when the CPU1 needs to switch off the clock it must always first get Sem0, even if not using the RNG IP. This mechanism is shown in the BLE P-NUCLEO-WB55.USB dongle examples (see
Figure 9). This does not impact the CPU2.
Section 7.1.3: Configuration and
AN5289 Rev 5 23/160
159
STM32WB software architecture AN5289
MS53124V1
RNG entry
Configure and switch on RNG clock
Exit
RNG process
Release Sem0
Poll Sem0 until granted
Switch off RNG IP
Switch off RNG clock
Set RNGSEL = CLK48

Figure 8. Algorithm to use RNG on CPU1

Note: Sem5 is not taken because the CPU2 does not take it without taking first Sem0. This
algorithm can be updated to take Sem5 before configuring the RNG clock source.
24/160 AN5289 Rev 5
AN5289 STM32WB software architecture
MS53125V1
USB entry
Configure and switch on CLK48
Exit
Switch on USB IP
Switch off CLK48
Poll Sem5 until granted
USB process
Switch off USB IP
Get Sem0
Sem0 granted ?
Release Sem0
Release Sem5
Enable Sem0 IT and wait for free interrupt
No
Yes

Figure 9. Algorithm to use USB on CPU1

The USB and RNG IPs share the same source clock. Before switching off the clock, the USB driver must first check whether the CPU2 requires the clock or not. To avoid a race condition with the CPU2, the CPU1 must first get Sem0 (RNG semaphore, CPU2 does not use USB) before switching off the clock.
If Sem0 is busy, the CPU1 must wait for Sem0 to be free to switch off the clock. This is required because there can be a race condition when CPU1 releases the USB and CPU2 releases the RNG at the same time, leading to the oscillator to be kept on.
Sem6 is used to protect the CPU1 timing versus write/erase operations requested by the CPU2. The CPU1 shall get Sem6 to prevent the CPU2 or other CPU1 processes to either write or erase data in Flash memory. There is no time limit on how long the CPU1 can keep the semaphore, but, as long as the semaphore is taken, the CPU2 is unable to write either the pairing or client descriptor information in the memory.
CPU1 has to release Sem6 only if it can afford being stalled for the time required to finish the write or erase operation.
The CPU2 implements the algorithm described in Figure 10, similarly to the CPU1. Before writing or erasing data in Flash memory, it tries to get Sem6 and, if successful, writes/erases
AN5289 Rev 5 25/160
159
STM32WB software architecture AN5289
data and releases the semaphore. When the CPU1 needs to protect its timing, it polls Sem6 until it gets it.
Sem7 is used to protect the CPU2 timing versus write/erase Flash memory operation requested by CPU1. The CPU1 must get Sem7 before writing or erasing. Sem7 must be taken and released for each single write or erase operation, but for not more than 0.5 ms in addition to the write/erase timing. To comply with this requirement the code must be executed in the critical section. The algorithm is described in
AES2 is reserved to the CPU2 and must never be used/accessed by the CPU1.
AES1 is reserved to the CPU1 and is never used/accessed by the CPU2. The only case when the CPU2 accesses the AES1 is when the CPU1 requests to write a user key on the customer key storage area. This is described in
Sem8 is used to ensure that CPU2 does not update the BLE persistent data in SRAM2 while CPU1 reads them.
The CPU2 may be configured to store the BLE persistent data either in the internal NVM storage on CPU2 or in the SRAM2 buffer provided by the user application. This can be configured with the system command SHCI_C2_Config() when the CPU2 is requested to store persistent data in SRAM2, so it can write data in this buffer when needed. To read consistent data with the CPU1 from the SRAM2 buffer, the flow must be:
1. CPU1 takes Sem8
2. CPU1 reads all persistent data from SRAM2 (most of the time, the goal is to write these data into an NVM managed by CPU1)
3. CPU1 releases Sem8
[6].
Figure 10.
There is no timing constraint on how long this semaphore can be kept.
Sem9 is used to ensure that CPU2 does not update the Thread persistent data in SRAM2 while CPU1 reads them.
The CPU2 may be configured to store the Thread persistent data either in the internal NVM storage on CPU2 or in the SRAM2 buffer provided by the user application. This can be configured with the system command SHCI_C2_Config() when the CPU2 is requested to store persistent data in SRAM2, so it can write data in this buffer when needed. To read consistent data with the CPU1 from the SRAM2 buffer, the flow must be:
1. CPU1 takes Sem9
2. CPU1 reads all persistent data from SRAM2 (most of the time, the goal is to write these data into an NVM managed by CPU1)
3. CPU1 releases Sem9
There is no timing constraint on how long this semaphore can be kept.

4.4 Sequencer

The sequencer executes registered functions one by one. It has the following features:
supports up to 32 functions
requests functions to be executed
enables / disables the execution of a function
provides a blocking interface based on the reception of an event.
26/160 AN5289 Rev 5
AN5289 STM32WB software architecture
The sequencer provides a simple background scheduling function. It provides a hook to implement a secure way Low-power mode (no event loss) when the sequencer does not have any pending tasks to be executed. It also provides an efficient mechanism for the application to wait for a specific event before moving forward. When the sequencer is waiting for a specific event, it provides a hook where the application may either enter
Low-power mode or execute some other code.

4.4.1 Implementation

To use the sequencer, the application must:
set the number of maximum of supported functions (this is done by defining a value for
UTIL_SEQ_CONF_TASK_NBR)
register a function to be supported by the sequencer with UTIL_SEQ_RegTask()
start the sequencer by calling UTIL_SEQ_Run() to run a background while loop
call UTIL_SEQ_SetTask() when a function needs to be executed.

4.4.2 Interface

Function Description
void UTIL_SEQ_Idle( void ); Called (in critical section - PRIMASK) when there is nothing to execute.
void UTIL_SEQ_Run( UTIL_SEQ_bm_t mask_bm )
void UTIL_SEQ_RegTask(UTIL_SEQ_bm _t task_id_bm, uint32_t flags, void (*task)( void ))
void UTIL_SEQ_SetTask( UTIL_SEQ_bm_t task_id_bm,
void UTIL_SEQ_PauseTask( UTIL_SEQ_bm_t task_id_bm )
void UTIL_SEQ_ResumeTask( UTIL_SEQ_bm_t task_id_bm )
void UTIL_SEQ_WaitEvt( UTIL_SEQ_bm_t evt_id_bm )
void UTIL_SEQ_SetEvt( UTIL_SEQ_bm_t evt_id_bm )
void UTIL_SEQ_EvtIdle(UTIL_SEQ_bm _t task_id_bm, UTIL_SEQ_bm_t evt_waited_bm)
Table 3. Interface functions
Requests the sequencer to execute functions that are pending and enabled in the mask mask_bm.
Registers a function (task) associated with a signal (task_id_bm) in the sequencer. The task_id_bm must have a single bit set.
Requests the function associated with the task_id_bm to be executed. The task_prio is evaluated by the sequencer only when a function has
finished. If several functions are pending at any one time, the one with the highest priority (0) is executed.
Disables the sequencer to execute the function associated with task_id_bm.
Enables the sequencer to execute the function associated with task_id_bm.
Requests the sequencer to wait for a specific event evt_id_bm and does not return until the event is set with UTIL_SEQ_SetEvt().
Notifies the sequencer that the event evt_id_bm occurred (the event must have been first requested).
Called while the sequencer is waiting for a specific event.
void UTIL_SEQ_ClrEvt( UTIL_SEQ_bm_t evt_id_bm )
UTIL_SEQ_bm_t UTIL_SEQ_IsEvtPend( void )
Clears the pending event.
Returns the evt_id_bm of the pending event.
AN5289 Rev 5 27/160
159
STM32WB software architecture AN5289

4.4.3 Detailed interface and behavior

The sequencer is a packaging of while loops to call functions when requested by the user:
while(1)
{
if(task_id1)
{
task_id1 = 0;
Fct1();
}
if (task_id2)
{
task_id2= 0;
Fct2();
}
__disable_irq();
If (! (task_id1|| task_id2))
{
UTIL_SEQ_Idle();
}
__enable_irq();
}
void UTIL_SEQ_Run(UTIL_SEQ_bm_t mask_bm)
Implements the body of the while (1) loop. The mask_bm parameter is the list of functions that the sequencer is allowed to execute. Each function is associated with one bit in that mask_bm. At the end of the startup, this API must be called in a while (1) loop with mask_bm = (~0) to allow the sequencer to execute any pending function.
void UTIL_SEQ_Idle( void )
Called under the critical section (set with the CortexM PRIMASK bit - all interrupts are masked) when the sequencer does not have any function to executed. This is where the application must enter the Low-power mode.
void UTIL_SEQ_RegTask(UTIL_SEQ_bm_t task_id_bm, uint32_t flags, void (*task)( void ))
Informs the sequencer to add the function task associated with the flag task_id_bm to its while loop.
void UTIL_SEQ_SetTask( UTIL_SEQ_bm_t task_id_bm , UTIL_SEQ_bm_t task_prio )
Sets the flag task_id_bm for the scheduler to call the associated function.
28/160 AN5289 Rev 5
AN5289 STM32WB software architecture
The task_prio is evaluated by the sequencer when it needs to decide which function to call next. This can be done only when the execution of the current function is finished. When several functions have their flag set, the one with the higher priority is executed (0 is the highest). This API may be called several times before the function is actually executed with a different priority. In that case, the sequencer records the highest priority. Whatever the number of API calls before the function is executed, the sequencer runs the associated function only once.
void UTIL_SEQ_PauseTask( UTIL_SEQ_bm_t task_id_bm ) :
Informs the sequencer not to execute the function associated with the flag task_id_bm even if it is set. If the API UTIL_SEQ_SetTask() is called after UTIL_SEQ_PauseTask(), the request is recorded but the function is not executed. The mask associated with UTIL_SEQ_PauseTask() is independent from the mask associated with
void UTIL_SEQ_Run(UTIL_SEQ_bm_t mask_bm).
A function can be executed only when its flag is set and enabled in both masks (default case).
void UTIL_SEQ_ResumeTask( UTIL_SEQ_bm_t task_id_bm ) :
Cancels the request done by UTIL_SEQ_PauseTask(). If this API is called when no UTIL_SEQ_PauseTask() has been requested, it has no effect.
void UTIL_SEQ_WaitEvt( UTIL_SEQ_bm_t evt_id_bm )
When this API is called, it does not return until the associated evt_id_bm signal is set. Only one bit in the evt_id_bm 32-bit value needs to be set. While the sequencer is waiting for this event, it calls UTIL_SEQ_EvtIdle() in a while loop on the event evt_id_bm. This has to be used to replace all code where a polling is made on a flag before moving forward.
void UTIL_SEQ_SetEvt( UTIL_SEQ_bm_t evt_id_bm )
Must be called only when UTIL_SEQ_WaitEvt() has already been called. It sets the signal evt_id_bm the function UTIL_SEQ_WaitEvt() is waiting for. Calling this API before the UTIL_SEQ_WaitEvt() function makes the call to UTIL_SEQ_WaitEvt() return immediately as the flag is already set.
void UTIL_SEQ_EvtIdle(UTIL_SEQ_bm_t task_id_bm, UTIL_SEQ_bm_t evt_waited_bm)
Called while the API void UTIL_SEQ_WaitEvt() is waiting for the signal to be set with UTIL_SEQ_SetEvt().
This API is weakly implemented in the sequencer to call UTIL_SEQ_Run(0), which means that while waiting for this event to occur, the function UTIL_SEQ_Idle() allows the system to enter Low-power mode while waiting for the flag.
The application may implement this API to pass parameters that are different from 0 to the UTIL_SEQ_Run(mask_bm). Each bit set to 1 in the mask_bm requests the sequencer to execute the function associated with this flag when it is set with UTIL_SEQ_SetTask(). This means that when the function UTIL_SEQ_WaitEvt() is called, while it is waiting for the requested event to return, it may either execute the unmasked functions when their flag is set, or call UTIL_SEQ_Idle() if no tasks is pending execution by the sequencer.
AN5289 Rev 5 29/160
159
STM32WB software architecture AN5289
void UTIL_SEQ_ClrEvt( UTIL_SEQ_bm_t evt_id_bm )
This API may be called when, in some applications, the API UTIL_SEQ_WaitEvt() needs to be called while Evt is already set. In that case, the Evt must be cleared.
UTIL_SEQ_bm_t UTIL_SEQ_IsEvtPend( void ):
This API returns the Evt that is currently pending. When several UTIL_SEQ_WaitEvt() are nested, it returns the last one, which means the one that makes the deeper UTIL_SEQ_WaitEvt() to return to its caller.

4.5 Timer server

The timer server has the following features:
Up to 255 virtual timers depending on available RAM capacity
Single shot and repeated mode
Stops a virtual timer and restarts it with a different timeout value
Deletes a timer
Timeout from 1 to 2
The timer server provides multiple virtual timers sharing the RTC wakeup timer. Each virtual timer may be defined as either single shot or a repeated timer. When a repeated timer comes to the end of a cycle, the user is notified and the virtual timer is automatically restarted with the same timeout. When a single shot timer ends, the user is notified and the virtual timer is set to the pending state (which means it is kept registered and may be restarted at any time). The user may stop a virtual timer and restart it with a different timeout value. When a virtual timer is no longer needed, the user must delete it to free the slot in the timer server.
32
- 1 ticks
The timer server can be used concurrently with the calendar.

4.5.1 Implementation

To use the timer server, the application must:
Configure the RTC IP. When the calendar is required in the application, the RTC
configuration must be compatible with the calendar settings requirement. When the calendar is not used, the RTC may be optimized for a Timer Server usage only.
Initialize the timer server with HW_TS_Init().
Implement HW_TS_RTC_Int_AppNot() (optional). When not implemented, the timer
callback is called in the RTC interrupt handler context.
Create a virtual timer with HW_TS_Create().
Use the virtual timer with HW_TS_Stop(), HW_TS_Start().
Delete the virtual when not needed using HW_TS_Delete().
30/160 AN5289 Rev 5
Loading...
+ 130 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use