|
Coming soon |
Please understand this is draft, thank you
1. X-CUBE-WW4 Pack content
This page addresses the content of the X-Cube firmware zip (currently X-CUBE-WW4_V0.7.0.zip).
Just to recapitulate from other pages, the ST WiFi solution is composed by two STM32xx devices: the host (MCU) and the WW4.
Following picture shows the case were the host is MPU but it is exactly the same for MCU.
The X-Cube firmware zip contains the code to be executed on the MCU Host (STM32H7 and STM32U5).
The X-Cube Firmware zip is organized in the typical way as most of packs delivered by STM.
This Wiki page will focus on the part of the pack specific to the Wi-Fi,
giving a brief description of the Middlewares and Applications folder organization.
Third party middlewares as (LwIP, MbedTLS, FreeRTOS, etc) are not covered by this page, because their folder structure is inherited from the public code.
2. ST Middlewares
2.1. WLAN_Driver
It is basically the code allowing the two chips communication (host and WW4) and WW4 FW download.
UMAC interface, RPC (Remote Procedure Call) and COM abstraction.
It is provided in source code.
Linux oriented. The folders are shared between MCU host, MPU host and with STM32WW4 device.
It occupies about 10 KB (MW) + 5 KB (SDIO) flash (on the host).
More details can be found in the dedicated WW4_Driver chapter in the Architecture Overview Wiki page.
2.2. WLAN_Lib and WPA supplicant
WLAN_API, wpa_supplicant, wpa_supplicant MCU customization.
WPA supplicant is given is source code, this comes from Linux distribution.
The customization of the WPA supplicant for MCU devices is given in library.
The WLAN_Lib is a bridge between application, WPA Supplicant, LWIP and WLAN_Driver.
This code is given in libraries.
Part of the WLAN_Lib is given in source code and part as a compiled libraries (.a)
These are the principal directories of the WLAN_Lib middleware:
- Api: include files with type definitions and functions prototypes offered by the WLAN_Lib to the application.
- Config: "WLAN_Lib/Config/wlan_driver_config.h" should be copied to the project space and to be used to configure the WLAN_Lib according to the specific project needs.
- Interface: the WLAN_Lib requests via these include files a set of callbacks or functions that the project must provide to allow the WLAN_Lib to be functional. Few examples, a way to allocate memory, a way to log messages, an interface with an IP stack, etc.
- Libraries: part of the implementation not provided in source. "WLAN_Lib/Libraries/libwlancore.a" and "WLAN_Lib/Libraries/libwlancommon.a" are always required by the linker. The other libraries are only for projects requiring the correspondent features.
- wpa_supplicant_bsd3: public WPA supplicant from Linux world.
- wpa_supplicant/ST_customization: Customization to STM32 MCUs.
Big code size, depends on the config and the libraries linked.
3. Projects
Projects are available for U5 and H7 boards.
Each project has similar structure, the picture below refers to CLI project, but other project are similar.
Basically, a project consists in five main entities:
- IDEs: directories containing the workspace for different IDEs (EWARM, STM32CubeIDE, Keil in future).
- Core: files related to the device (U5, H7, etc.) typically generated with CubeMX. Interrupt handling, MSP HW configuration (UART, DMA, TIM, etc)
- Middlewares configuration and interfaces: Similarly to WLAN_Lib above described, often middlewares modules need to be configures and requires some interfaces. The directories "LwIP/", "MBEDTLS/", "Trace/", "WLAN_DRIVER/" have a /Target subdirectory meant to provide to the correspondent middleware the necessary code to be functional.
- WW4 binary: It is placed in "WLAN_Driver/Binary". It is downloaded to the STM32WW4 by the application during initialization.
- Application: The application resides on the top, it uses several middleware modules and drivers. It needs to be centralized in a common place; due to some CubeFw restriction, it is decided to place* the application in the "WLAN_Lib/App" directory (in spite it handles also other middlewares then WLAN_Lib).
(*) The project WLAN_Driver_Prod application is an exception, since it does not use WLAN_Lib middleware, the application is placed in "WLAN_Driver/App".
Depending on the project other directories might be added for specific cases:
- Iperf : used by WLAN_Lib_CLI project to group iPerf2 files
- Dbgww4 : used by WLAN_Driver_Prod and WLAN_Lib_CLI projects to have direct communication with STM32WW4.
- Eeprom: used by WLAN_Lib_Fota and WLAN_Lib_Provisioning to emulate EPROM (read/store data in flash memory).
- Html: used by WLAN_Lib_HTTP_Server and WLAN_Lib_Provisioning to keep the web pages of the server.
other might come.
3.1. IDEs: Build and Install
Applications are delivered with both STM32CubeIDE and EWARM project files.
3.1.1. STM32CubeIDE
- Open the STM32CubeIDE project file.
- Right click on the project, go to Properties and check all the wlan libraries you need can be found by the linker: wlancore, wlancommon +additionnal features need to be linked, and libraries must be placed in the "Libraries search path"
- Right click on the project, and Rebuild all
- When the build is complete, right click on the project, and Run as -> STM32 C/C++ Application
Note :For more information about libraries content and dependencies, refer to X-CUBE-WW4_Architecture_Overview,
3.1.2. EWARM
- Open the EWARM project file.
- Right click on the project, go to options and check all the wlan libraries (with the path to it) you need can be found by the linker: wlancore, wlancommon +additionnal features need to be linked,
- Right click on the project, and Rebuild all
Note :For more information about libraries content and dependencies, refer to X-CUBE-WW4_Architecture_Overview,
3.1.3. STM32CubeProgrammer
If you already have the binaries, you can flash the board with STM32CubeProgrammer:
- Start STM32CubeProgrammer
- Connect to the board with STLink
- Go to Erasing & Programming section
- Select your file
- Click Start Programming
3.1.4. Serial Link
See logs and traces.
3.2. Core
Compatible with CubeMX generation. Typical to CubeFw, no need to detail about it.
3.3. Middlewares configuration and interfaces (/Target)
Code is placed in the "/Target" directories: "WLAN_LIB/Target", "WLAN_DRIVER/Target", "LWIP/Target", etc.
3.3.1. Middlewares configuration
Most important configuration files of the middlewares are:
- "WLAN_LIB/Target/wlan_lib_config.h": few definitions to configure the WLAN_Lib and wpa supplicant provided in source code.
- "WLAN_DRIVER/Target/wlan_driver_config.h": definitions to configure the WLAN_Driver.
- "Core/Inc/FreeRTOSConfig.h": definitions to configure the FreeRTOS. There is no dedicated "/Target" directory for it.
- "LWIP/Target/lwipopts.h and lwippools.h": definitions to configure the WLAN_Driver.
"LWIP/Target/lwipopts.h" configuration is quite important but it will not be covered here a part to some specific topic.
Just take care that in the release 0.7.0 the ACD (Address Collision Detection) feature is enable and it dramatically slows down the DHCP when obtaining the IP address (more then 10 seconds instead of a couple of seconds). This can be avoided by setting the below compilation flag:
#define LWIP_DHCP_DOES_ACD_CHECK 0
LwIP pull buffers configuration and FreeRTOS heap memory configuration will be discussed in a separate chapter dedicated to memory, transversal to application and middlewares.
Logs configuration will be discussed in a separate chapter dedicated to logs and traces, transversal to application and middlewares.
3.3.2. Middlewares interfaces
The interfaces often don't belong strictly to a specific middleware, but they make bridges between middlewares or are used by more the one middleware.
In such cases interfaces are put in the "WLAN_LIB/Target" (similarly the application cross middlewares which is put in the "WLAN_LIB/App" directory)
Let's mention the most important:
- "wlan_netif_lwip.c", "wlan_netbuf_lwip.c" and "app_lwip_cb.c" make the bridge bewwen the "WLAN_Lib" and the "LWIP" middlewares. The files are placed in the "WLAN_LIB/Target" directory.
- "wlan_os.c" mainly operative system abstraction requested by both "WLAN_Lib" and "WLAN_Driver" it is placed in the "WLAN_LIB/Target" directory.
- "com_sdio.c" and "sdio_drv.c" allow the Host device to communicate with the WW4 device (via SDIO or SPI). For the moment only SDIO implementation is provided. The files are placed in the "WLAN_DRIVER/Target" directory.
3.4. WW4 binary
Binary placed in the "WLAN_DRIVER/Binary" directory.
Latest X-CUBE-WW4 release (v_0.7.0) uses following binary: stm32ww4_wifi_fw_reg_cut_2_0.bin.
It occupies about 128 KB.
Remind: STM32WW4 does not have flash memory. During initialization phase the host device loads the code into the STM32WW4 RAM where it is executed. For more details, please have a look at Architecture Overview - FW_loader.
3.5. Application
While the above files and directories remains pretty similar between different projects, the code that makes them different between one and the other is the application, placed in the directory "WLAN_Lib/App".
Here there are several files and again most of them are common between applications, few are completely different.
Let's see this more in detail.
Most applications use a "didactical" layer, providing functions that groups a sequence of LWIP and WLAN_Lib functions call, and other functions to print out on the hyper terminal didactical messages about the state of the application. This layer also provides function for facilitate the debug and to get performance or memory usage statistics.
This layer is constituted by files like : "app_common.c, app_handlers.c, uart_if.c, util_led_pb.c, util_net_address.c, util_net_mem.c, util_net_perf.c " located in "WLAN_Lib/App".
Actually, only WLAN_Lib_Ping does not use this "didactical" layer, because is targeted for experienced developers that want to start writing their application from zero, by interfacing directly with the middlewares with minimal overhead.
The file that that really change from one application to the other is : " WLAN_Lib/App/main_app.c".
It is the entry point, often other specific files come to complement it depending on the application, for example:
"WLAN_Lib/App/generic_mqtt.c, ../httpserver.c, ../ping_addr.c, ../ping_dns.c, ../console.c, etc"
More details about them will be given in the wiki pages specific to each application.
Other two files deserve to be mentioned because users need to configure them for adapting any application to their environment:
The files are "app_conf.h" and "credentials_and_ip_static_addr.h" located in "WLAN_Lib/App".
The first contains general definition depending on the specific application.
The second contains the SSID, password, IP address, netmask, etc. of the local access point to which user wants to connect.
Next chapters refer to code placed in the "WLAN_Lib/App" but their scope sometime is more general than just the application or in any case the deserve to be discussed in a general context. For example, the file "WLAN_Lib/App/msg.h" configures the application logs, but it is wise to talk about it in a unique cross chapter that explain how to configure logs as well in the other modules.
3.6. IPv6
3.6.1. SW and HW requirement
IPv6 needs nucleo boards with STM32WW4 device at least cut 2.1. Most of the boards we have (and the one distributed so far to FAEs and Alpha customers) are cut 2.0. IPv6 is available in the X-CUbe-WW4 release version 0.8.0. By default, this release 0.8.0 uses still cut 2.0, meaning that it links the libraries built for that:
- ..\Firmware\Projects\STM32WW_Copro_Binaries\STM32WW4xx\stm32ww4_wifi_fw_reg_revB_auth.bin
with that library IPv6 fail to handle IPv6 broadcasted messages which are necessary to establish the communication. Release 0.8.0 does not support the intermediate version cut 2.1, but directly the version cut 2.2, which uses following library:
- ..\Firmware\Projects\STM32WW_Copro_Binaries\STM32WW4xx\stm32ww4_wifi_fw_reg_revY_auth.bin
If you don't have a board cut 2.2, but just a cut 2.1 you need to work in a developer branch were cut 2.1 is still supported.
- __INTERNAL__Projects: bz/170773_ipv6_dev2 (SHA-1: 42a8851393f5c08f7a6308f92b9a1eae06771b02)
- WLAN_Lib: st_main (SHA-1: 8831feca58f7be3a14c36d55120d76217cc979ef)
- WLAN_Driver: st_host_ww4_driver (a8a6c34121ca30874504e77aa6a0290ec8f9e170)
In this project you will find the libraries for cut 2.1.:
- ..\Firmware\Projects\STM32WW_Copro_Binaries\STM32WW4xx\stm32ww4_wifi_fw_reg_revZ.bin
To update your project (example for IAR): Project -> Options -> Linker -> Input the select the raw binary image corresponding to your board:
- cut 2.0 : revB
- cut 2.1 : revZ
- cut 2.2 : revY
3.6.2. LWIP Middleware patch and Bz ticket
v2.2.0_20240202 tag is used for LwIP middleware. However this version needs to be patched to get it working for IpV6 The requested changes are reported in the ticket 181742.
Following lines should be added in the nd6_input() function, file nd6.c line 476
if(ip6_addr_isany(ip6_current_src_addr()) &&
ip6_addr_issolicitednode(ip6_current_dest_addr()){
pbuf_free(p);
ND6_STATS_INC(nd6.drop);
return;
}
Notice also that the IpV6 addresses generated by LwIp based on MAC address are not compliant with the EUI-64 format. The problem is reported in the ticket 183060.
3.6.3. IpV6 Infrastructure (gateway for STA applications)
3.6.3.1. Tips for STA applications
Make sure the access point to which you connect the STM32WW4 STA device support IpV6.
It is also possible that the AP (e.g the Tp_link_xx) supports the IpV6 only locally but not for Internet connection. This can also depend by the Internet provider contract. For example, our TP_Link does not allow to set Internet in Ipv6 mode when using the Buygues telecom SIM card (4G). But when connecting the gateway to the Orange Livebox through the Ethernet cable, then it can be configured to Ipv6. Make sure the Livebox is also configured in IPv6 mode. Given all that you will be able to access the internet world, like:
- pingURL6 google.com
- echo (it will echo "2A05:D018:21F:3800:3164:2A5C:75B3:970B" port 7)
- http_download (it will resolve "http://public.st.free.fr/500MO.bin")
If, for the reasons explained earlier, the AP does not allowed to access the internet, it might still be possible to configure it for local Ipv6 network.
In this case, please use the WLAN_Lib_Ping project and ping the IPv6 address of the AP. If you connect several devices to the AP (several STM32ww4 devices or other devices like PC and smartphones) you should be able to ping in Ipv6 between them.
3.6.3.2. Tips for Soft-AP applications
In this case the AP is the STM32WW4 device itself, to which you connect from your PC or smartphone. On the PC internet browser (e.g. Edge, Chrome, Firefox) you should type the Ipv6 address of the STM32WW4 device hosting the HTTP server, by using following this syntax:
- http://[fe80::xxxx:xxxx:xxxx:xxxx] example: [fe80::80:e156:6814]
Not all systems or browsers are capable to handle that. For example, it does not work with my smartphone but neither with the Linux laptop. It works with my personal Windows PC at home using Edge browser. Initially Firefox didn't work but after having used Edge, Firefox started working as well.
Before using the browser, you can check that the connection is established by pinging the device. Here the syntax example (you don't need square brackets):
- With Windows: ping -6 fe80::80:e156:6814
- With Linux: ping6 fe80::80:e156:6814%if_name
3.6.3.3. Tips for P2P applications
No special tips for P2P applications, you need two STM32WW4 devices, they should work like for IpV4.
3.6.4. How to enable the applications for IpV6
IPv6 can be enabled in the app_conf.h setting the following flag:
- #define NET_USE_IPV6 1
Notice that when the NET_USE_IPV6 is 1, the application only works in IPv6 mode and not anymore in IPv4. This is just because the socket will be opened by the application in IPv6 mode. It is not a restriction, if the application would create both ipv4 and ipv6 addresses and it would sequentially run commands on Ipv6 sockets and then ipv4 sockets, it should work. But so far, current applications has been written to execute one mode or the other.
Notice that the applications are implemented such that the IPv6 address is assigned statically. DHCP mode for IPv6 it has not been implemented so far. But it is not essential in IPv6 mode.
All applications have been implemented to support IPv6 but some not tested or with restrictions:
- WLAN_Lib_Ping: implemented and tested in SOCKET mode (not implemented in raw mode)
- WLAN_Lib_Echo: implemented and tested, you need a gateway with IPv6 internet access to run it
- WLAN_Lib_MQTT: implemented but not tested (it would require an MQTT broker working in IPv6)
- WLAN_Lib_CLI: implement and test for Ping, Http download and Echo. Iperf not tested. Specific Ipv6 commands not added.
- WLAN_Lib_HttpServer: implemented and tested by connecting with Windows PC using Edge browser.
- WLAN_Lib_Provisioning: implemented and tested by connecting with Windows PC using Edge browser.
- WLAN_Lib_WiFiDirect: implemented and tested by connecting two STM32WW4 devices.
3.7. Read-Write (RW) Memory setting
3.7.1. Dynamic memory
Dynamic memory is allocated in the FreeRTOS heap instead Lib-C HEAP .
The application code in "WLAN_Lib/App/util_net_mem.c" redirect all calls to "malloc", "calloc", "realloc" and "free" form the classical Lib-C HEAP to the FreeRTOS memory basically using "pvPortMalloc()" and "vPortFree()".
The advantage is that no matter which module, it could be also Third_Party middleware with hardcoded calls to "malloc", all dynamic memory allocation centralized in the FreeRTOS memory.
The classical HEAP memory instantiated in the linker file is therefore no more used and can be minimized, on the other hand the FreeRTOS HEAP shall be configure depending on the project. Configuration is done in the "Core/Inc/FreeRTOSConfig.h".
Examples of values for the different applications: #define configTOTAL_HEAP_SIZE ((size_t)15000) /* APP_PROD */ #define configTOTAL_HEAP_SIZE ((size_t)130000) /* APP_CLI */ #define configTOTAL_HEAP_SIZE ((size_t)100000) /* APP_PROVISIONING*/ #define configTOTAL_HEAP_SIZE ((size_t)100000) /* APP_HTTPSERVER*/ #define configTOTAL_HEAP_SIZE ((size_t)130000) /* APP_P2P*/ #define configTOTAL_HEAP_SIZE ((size_t)100000) /* APP_WPS*/ #define configTOTAL_HEAP_SIZE ((size_t)100000) /* APP_ENTERPRISE*/ #define configTOTAL_HEAP_SIZE ((size_t)60000) /* APP_ECHO*/ #define configTOTAL_HEAP_SIZE ((size_t)60000) /* APP_MQTT*/ #define configTOTAL_HEAP_SIZE ((size_t)60000) /* APP_PING*/ #define configTOTAL_HEAP_SIZE ((size_t)80000) /* APP_FOTA */
The application code in "WLAN_Lib/App/util_net_mem.c" allows also to report information on the heap memory usage.
This option is available by enabling the flag "NET_ALLOC_DEBUG" in the "WLAN_Lib/App/app_conf.h".
The information is displayed on the hyper terminal when calling the function "net_alloc_report()", typically when the application ends.
3.7.2. LwIP Pull buffers ( lwippools.h and lwipopts.h)
Pull buffers are defined in the "LWIP/Target/lwippools.h" but a cople of parameters that determines the final size are in the "LWIP/Target/lwipopts.h"
#define ARP_DNS_POOL_BUFSIZE 256 #define TX_POOL_BUFSIZE 1580 /* Dedicated Pool for DNS client context and ARP buffer allocation */ LWIP_MALLOC_MEMPOOL(2, ARP_DNS_POOL_BUFSIZE) /* Two Dedicated Pools for LwIP TX buffer */ LWIP_MALLOC_MEMPOOL(TX_COUNT, TX_POOL_BUFSIZE) /* 1664 bytes buffer is shared between LwIP TX buffers and other supplicant command like scan */ LWIP_MALLOC_MEMPOOL(1, 1664)
The number of the buffers "TX_COUNT" can be quite different depending on the size to be transferred or on the performance that we want to achieve. For most projects "TX_COUNT = 2" is sufficient, this is minimal requirement if you have memory restriction. Most of our projects will be configured with "TX_COUNT = 5". But when we need high performance like to get a good iPerf throughput in the WLAN_Lib_CLI project, the number of pull buffers is increased to 44.
When the application needs to use LwIp mem_alloc (see for example ping_ipaddr.c and ping_url.c implementations) correspondent memory pull should be added. For example for ping size up to 256 buffer size the following is added:
#define PING_POOL_BUFSIZE 288 /* (256+34) allows to ping up to 256 */ LWIP_MALLOC_MEMPOOL(1, PING_POOL_BUFSIZE)
Ping can have size up to MTU limit, in that case PING_POOL_BUFSIZE should be 1534.
User developing his own application should remind to add its memory requirement in these LWIP configuration files.
3.7.3. Logs RW memory
There is a dedicated chapter related to logs, which are highly configurable.
Limited to the RW buffers used for DMA transfer they can be configured mainly in the "Core/Inc/utilities_conf.h" (increasing "UTIL_ADV_TRACE_TMP_BUF_SIZE" value) and in the "WLAN_LIB/Target/wlan_os.c" (see "uint8_t a_uart_buff[4096];").
The project that demands bigger allocation is again WLAN_Lib_CLI because the CLI allows customers to choose dynamically the verbose level.
3.7.4. RW Memory footprint
Each project (application) will detail its memory footprint for both RO and RW memory.
This chapter only gives some numbers about RW buffer to complete what written in previous paragraphs.
In particular following print-shot shows how the main contributors for the RW memory are the FreeRTOS heap (in green) and the LWIP buffers (in yellow). Which modules allocates the FreeRTOS heap is not detailed here. The printshot reflect the configuration used by default in the current X-CUBE-WW4 release (ver_0.7.0).
3.8. Debug: Logs, Trace, Performance measurements
3.8.1. Hyper Terminal setup
Any hyper terminal can be used, the below configuration example comes from Tera Term. Tera Term is an open-source and freely available software terminal emulator, which is used to display log messages of the WLAN_Lib_Fota through a serial connection. Users can download and install the latest version available from the Tera Term download website. Otherwise they should be able to use any other terminal emulator software.
Once the Nucleo board is connected to the PC, start Tera Term and select the proper connection featuring the [STMicroelectronics STLink Virtual COM Port]. For the screenshot below this is COM5 but it could vary for different users and boards.
Set the Terminal parameters from the menu command Setup > Serial_Port...:
Set the Terminal parameters from the menu command Setup > Terminal...:
Note: New-line option must be set both to LF
3.8.2. Logs configuration
There are many flags to be tune for enabling/disabling the logs, each Middleware has its own, and the application as well.
Sometime the verbose level is selectable dynamically sometime at compilation time.
Sometimes it saves ROM memory (the sting to be printed is removed from the binary) sometime not.
In all cases the logs reach the hyper terminal via the utility ADV_TRACE that uses the the DMA to send a circular buffer of characters on the UART.
3.8.2.1. Application logs (file "WLAN_Lib/App/msg.h")
Application logs are enabled/disabled at compilation time in the file "WLAN_Lib/App/msg.h"
Disabling these logs allows reducing the memory footprint, but be aware that most of logs are not in the application;
so this will only allow to save about 3KB flash memory.
#define ENABLE_APP_MSG_DEBUG 0 #define ENABLE_APP_MSG_INFO 1 #define ENABLE_APP_MSG_WARNING 1 #define ENABLE_APP_MSG_ERROR 1 #define ENABLE_APP_MSG_ASSERT 1 #define ENABLE_IPERF2_MSG 1
The file "WLAN_Lib/App/msg.h" includes a descriptive part to tell where to enable / disable middlewares logs, which is also done in the next paragraph of the Wiki page.
3.8.2.2. WLAN_Lib / WLAN_Driver logs
The WLAN_Lib / WLAN_Driver allows both compilation flags and dynamic level.
If the LOG compilation flags are disabled of course trace are not available at all (remove from the binary, hence flash memory saved).
If the LOG compilation flags are enabled, then verbose level can be selected dynamically via a CLI command.
Basically the filtering of logs to be displayed is done by the function "wlan_os_printf_impl(logLevel, text)" implemented in the file "WLAN_LIB/Target/wlan_os.c",
depending on the verbose level that has been previously set by the function "wlan_os_set_print_lvl(PrintLevel)".
Possible levels are:
WLAN_OS_PRINT_ALL = 0, /*!< Print all messages (DBG + INFO + ERR) */ WLAN_OS_PRINT_DBG = 1, /*!< Print debug and lower messages (DBG + INFO + ERR) */ WLAN_OS_PRINT_INFO = 2, /*!< Print info and lower messages (INFO + ERR) */ WLAN_OS_PRINT_ERR = 3, /*!< Print error messages (ERR) */ WLAN_OS_NO_PRINT = 4, /*!< Dont print any message */
If "WLAN_OS_PRINT_ALL" or "WLAN_OS_PRINT_DBG" are set by "wlan_os_set_print_lvl()" some messages might be lost.
This can be avoided by using larger buffers as described in the above chapter: Logs RW memory.
We have three modules using this method WLAN_Lib, WLAN_Lib_wpa_Supplicant and WLA_Driver.
- WLAN_Lib : it is given in libraries (.a) so it cannot be recompiled. The provided version supports logs. A version not supporting logs can be provided on request: it allows saving 30KB flash memory.
- WLAN_Lib/wpa_Supplicant : it is given in source code, logs can be enabled by the compilation flag "WLAN_LIB_WPA_LOG_ENABLE" in the "WLAN_LIB/Target/wlan_lib_config.h". This has huge impact on memory size (about 300KB).
- WLAN_Driver : it is given in source code, logs can be enabled by the compilation flag "WW4_LOG_ENABLE" in the "WLAN_DRIVER/Target/wlan_driver_config.h". This has minor impact on memory size (about 3KB).
In the current version of X-CUBE_WW4 (v_0.7.0) the WLAN_Lib libraries are compiled to support the logs. On the contrary the "WLAN_LIB_WPA_LOG_ENABLE" and "WW4_LOG_ENABLE" compilation flags are conditioned to the DEBUG mode, so not defined when compiling with IAR and CubeIDE RELEASE configuration, and defined only for CubeIDE DEBUG configuration.
3.8.2.3. Third party Middlewares logs
Each Middleware is suppposes to provied an interface for redirecting the logs.
The most important is surely the LWIP, the log configuration is done in following file:
"\Applications\WLAN_Lib\<ApplicationName>\LWIP\Target\cc.h"
Notice that mbedTLS has a log system with dedicated API, a part of enabling the compilation flags in the "mbedtls_config.h"
the implementation should be implemented in the correspondent interface file (similarly to what is done in "WLAN_LIB/Target/wlan_os.c" for WLAN_Lib\Driver).
3.8.3. Logging implementation: how logs are sent to the hyper terminal
Logs reach the hyper terminal via the utility ADV_TRACE that uses the DMA to send a circular buffer of characters on the UART.
"UTIL_ADV_TRACE_COND_FSend()" post data to the circular queue for printing.
"UTIL_ADV_TRACE_COND_Send()" would also allow to set a "VerboseLevel" for filtering but this feature is not used (always true) since already implemented by the Middlewares.
A function that deserves to be mentioned is "UTIL_ADV_TRACE_IsBufferEmpty()": when trace buffer is full it allows to wait (kind of polling mode) that there is enough space to complete the messages. This is useful when no time constraint, like when printing the help message, or the scan results. It should not be used to compensate the high verbose level (e.g. DEBUG lgs), because it has consequence on the real time. For such cases the trace buffer should be increased in the "Core/Inc/utilities_conf.h" and in the "WLAN_LIB/Target/wlan_os.c" files (as explained earlier).
3.8.4. LwIP GPIO indicator
Led or GPIOs can be used to indicate LwIP activity.
This is currently implemented in the "Target/" files "wlan_netif_lwip.c" and "app_lwip_cb.c" in "WLAN_LIB/Target" directory.
When RX or TX functions are called the BLUE Led on STM32U5 boards or the ORANGE Led on the STM32H7 boards is switched ON.
A software timer is armed which switches OFF the Led 10ms later.
Notice that, when measuring the throughput with iPerf, current implementation it degrades performances.
So, for CLI project this indicator has been disabled.
In final release this will be implemented better, probably using an HW timer (HAL_TIM) instead of FreeRTOS timer.
Notice that before LwIP data is exchanged, the same GPIO (Led) also blinks at initialization (regularly once every second) to indicate when the STA device is alive, it is connecting to a Local Access Point and establishing the LwIP connections. This is handled by a dedicated task and it stops blinking once the connection is established. Them the GPIO is used exclusively for the LwIP tx/rx activity as described above.
3.8.5. Performance measurements
"WLAN_LIB/App/util_net_perf.c" implements a set of functions that allows to print on the hyper terminal statistic about the tasks used.
Currently is only activated for the project WLAN_Lib_CLI and WLAN_Lib_FOTA.
In order to get the statistic, you need to quit the CLI project by prompting the "quit" command.
If you wish to add this feature in other projects, you have to call the functions "net_perf_start()" and "net_perf_report()" respectively to the begin and the end of the application and you have to register following hooks in the "FreeRTOSConfig.h" file
#define traceTASK_SWITCHED_IN net_perf_task_in #define traceTASK_SWITCHED_OUT net_perf_task_out
3.8.6. Read-Only (RO) memory footprint
Read-Only (RO) memory footprint is given in the scope of each single project.
It should also be given in the scope of the Middleware description, to show the impact of each sub-library (STA, AP, P2P, etc.) and correspondent supplicant code, and also to detail the impact of MW configuration compilation flags. See Architecture Overview - Memory Footprint page.
The below print shot could be considered redundant; in fact, it has the specific scope to give a quick visual comparison between the provided applications.
The "WLAN_Driver_prod" is much smaller than other projects because it does not include most of the MWs ("WLAN_Lib", "WPA_Supplicant", "LwIP", "MbedTLS") are not requested by this project. Actually, its size is mostly given by the WW4 binary (the last shown in yellow).
On the contrary "WLAN_Driver_CLI" includes all MWs, this is why is the biggest.
The application is typically relatively small, it is notable only in the "WLAN_Driver_CLI" project due to the console commands implementation, and it looks even bigger for "WLAN_Driver_Provisioning" but this is just because the images (*.svg) of the HTML pages are counted as application code (about 80% of it).