1. Introduction
The Zigbee stack is a software component designed to enable Zigbee communication on the STM32WB/WBA microcontroller. Like any software, the Zigbee stack requires memory to operate. There are two main types of memory that are relevant to the stack: RAM and Flash memory.
RAM (Random Access Memory) is a type of volatile memory that is used for temporary storage of data and program code. The Zigbee stack uses RAM to store data structures, variables, and other runtime objects.
Flash memory, on the other hand, is a type of non-volatile memory used for long-term storage of program code and data. The Zigbee stack uses flash memory to store the code and data that make up the Zigbee stack itself. The amount of flash and RAM required depends on the application and the features used.
| Memory types in microcontroller |
|---|
Another important concept to understand is memory allocation. The application uses a heap to allocate memory dynamically at runtime. This means that the Zigbee stack can allocate memory as needed, rather than requiring a fixed amount of memory to be allocated at compile time. However, this also means that the Zigbee stack requires some amount of overhead to manage the heap.
Developers should carefully consider their application's requirements and consult the Zigbee stack's documentation to determine the appropriate memory requirements.
2. Startup file and linker script
The startup file and the linker script allow initializing the microcontroller's hardware and link the various sections of the code together.
The startup file includes functions that set up the stack, initialize the memory, and configure the clock and other peripherals so that the user application can run. The linker script determines how the code and data are organized in memory. It defines the ROM_start, ROM_end, RAM_start, and RAM_end for example.
2.1. Linker file on STM32WB
The following figure shows the memory map representation of the On/Off STM32WB55.Nucleo application example of the STM32Cube MCU Package. We have two separate linker files: the first for M4 and the second for M0, which is common and necessary to ensure that the code and data are placed in the correct memory regions for each core.
3. STM32WB Zigbee software architecture
As a reminder, the STM32WB MCUs are built with two separate cores, Arm® Cortex®-M4 and Arm® Cortex®-M0+ cores. The architecture is depicted in the figure below. Mainly, the M0 core contains the Zigbee stack, and the M4 core contains clusters and the developer’s application.
| STM32WB Zigbee architecture |
|---|
STM32WB contains up to 1 Mbyte of flash memory single bank architecture, can be accessed starting from address 0x0000 0000 or 0x0800 0000, internal SRAM1 (up to 192 KB) and internal SRAM2a (32 KB) + SRAM2b (32 KB).
4. STM32WB stack memory requirements
4.1. STM32WB stack heap
During the initialization of the Zigbee stack, the M0 core allocates memory for the stack through IPCC calls to the M4 core. When the Zigbee stack running on the M0 core invokes `ZbMalloc()`, it triggers the sending of a `MSG_M0TOM4_ZB_MALLOC` message to the IPCC. Upon receiving this message, the M4 core allocates memory from its heap (using `malloc`) and returns a pointer to the M0 core. This mechanism ensures that memory passed between the two cores via IPCC API calls is accessible to both cores. However, the M4 core is restricted from accessing other memory areas within the M0 core.
The application can configure the heap size and the number of network tables using the `ZbInit()` function. The Zigbee stack requires a certain amount of heap memory at startup to allocate various network tables, runtime objects, endpoints, and packets.
ZbInit(uint64_t extAddr, struct ZbInitTblSizesT *tblSizes, struct ZbInitSetLoggingT *setLogging)
If the tblSizes parameter is set to NULL, default values are used for the number of network tables (as detailed in the chapters below), and the heap size is set as follows:
- FFD SW : 32 KB
- RFD SW : 16 KB
Depending on the topology and use case, the application can modify these default settings by adjusting the tblSizes parameter. The tblSizes structure contains two key parameters, heapPtr and heapSz, which can be used to configure the heap utilized by the stack. Additionally, it includes fields to set the number of tables in use.
4.2. STM32WB Zigbee application footprint
Note : These values are based on the V1.20 Cube Firmware release.
| Application | Flash (KB) | RAM (KB) | |
| M0 | ZigbeeR22 FFD stack
(stm32wb5x_Zigbee_FFD_fw) |
Total= 335.7 |
Total= 19.5 |
| ZigbeeR22 RFD stack
(stm32wb5x_Zigbee_RFD_fw) |
Total= 276 |
Total= 14.8 | |
| Dynamic concurrent mode: BLE + ZigbeeR22 RFD stack
(stm32wb5x_BLE_Zigbee_FFD_dynamic_fw) |
Total= 480 |
Total= 53.7 | |
| Dynamic concurrent mode: BLE + Zigbee R22 RFD stack
(stm32wb5x_BLE_Zigbee_RFD_dynamic_fw) |
Total= 420 |
Total= 49 | |
| Static concurrent mode: BLE + Zigbee R22 RFD dynamic stack
(stm32wb5x_BLE_Zigbee_FFD_static_fw) |
Total= 472 |
Total= 51 | |
| Static concurrent mode: BLE + Zigbee R22 RFD static stack
(stm32wb5x_BLE_Zigbee_RFD_static_fw) |
Total= 411.5 |
46 | |
| M4 | Zigbee_OnOff_Server_Coord (FFD) | 59 | 114 |
| Zigbee_OnOff_Client_Router (FFD) | 59 | 114 | |
| Zigbee_OnOff_Client_SED (RFD) | 54 | 109 | |
| Zigbee_Find_Bind_Coord (FFD) | 71 | 114 | |
| BLE_Zigbee_Dyn (BLE + FFD) | 64 | 114 |
4.3. STM32WB stack tables size and SRAM memory configuration
The ZbHeap size should be carefully tuned according to the topology. As explained in chapter 5.2.7, the number of tables allocated at startup by the stack can be configured via the function ZbInit through the parameter tblSizes.
All the Zigbee tables are allocated dynamically at startup when calling ZbInit().
ZbInit(uint64_t extAddr, struct ZbInitTblSizesT *tblSizes, struct ZbInitSetLoggingT *setLogging)
If the parameter tblSizes is set to NULL, the default number of tables in use are as follows:
| Default config until v1.20 | FFD | RFD |
| Number of NWK_NEIGHBOR_TABLE | 16 | 15 |
| Number of ZB_NWK_NLME_ADDRMAP_TABLE | 16 | 15 |
| Number of ZB_NWK_NLME_ROUTE_TABLE | 16 | 15 |
| Number of ZB_NWK_NLDE_BTT_TABLE | 16 | 16 |
| Number of ZB_NWK_NLME_RREQ_TABLE | 4 | 4 |
| Number of ZB_APS_DEVICE_KEY_PAIR_COUNT | 16 | 15 |
For the new upcoming releases, the default number of tables (starting from firmware version v1.21), is as follows:
| Upcoming Release config | FFD | RFD |
| Number of ZB_NWK_NEIGHBOR_TABLE | 64 | 16 |
| Number of ZB_NWK_NLME_ADDRMAP_TABLE | 32 | 2 |
| Number of ZB_NWK_NLME_ROUTE_TABLE | 32 | NA |
| Number of ZB_NWK_NLDE_BTT_TABLE | 32 | 9 |
| Number of ZB_NWK_NLME_RREQ_TABLE | 16 | NA |
| Number of ZB_APS_DEVICE_KEY_PAIR_COUNT | 32 | 2 |
The meaning of these definitions is described in chapter 5.2.7.
The following table describes the impact on memory usage for each additional entry:
| Entry Type | Table Name | Memory Usage Per Entry (bytes) |
| Network Neighbor Table entry (nwkNeighborTblSz) | NWK_NEIGHBOR_TABLE | 144 |
| Network Routing Table entry (nwkRouteTblSz) | NWK_NLME_ROUTE_TABLE | 28 |
| Network Address Mapping Table (nwkAddrMapTblSz) | NWK_NLME_ADDRMAP_TABLE | 24 |
| APS Link Key Table (apsPeerLinkKeyTblSz) | APS_DEVICE_KEY_PAIR | 48 |
With this type of configuration, overall M4 ZbHeap consumption used for the Zigbee stack is close to 52 KB with 32 KB allocated for M0 ZbHeap + fixed M0 allocation + variable memory size, depending on topology.
To compute M4 heap requirement for a given topology, use the formula below:
M4 heap size = NB_NWK_NEIGHBOR_TABLE * 144
+ NB_NWK_NLME_ROUTE_TABLE * 28
+ NB_NWK_NLME_ADDRMAP_TABLE * 24
+ NB_APS_DEVICE_KEY_PAIR_COUNT * 48
+ (32+16)*1024
5. Acronyms and definitions
| Term | Definition |
|---|---|
| RAM | Random Access Memory |
| SRAM | Static Random Access Memory |
| ROM | Read Only Memory |
| FFD | Full Function Device |
| RFD | Reduced Function Device |
| SED | Sleepy End Device |
| NVM | Non-Volatile Memory |
[[Category:|10]]