Further Steps

Wi-Fi Commissioning Logs

The example outputs logs on the serial port, this logs allows to keep track of the program execution by tracing information about:

The image below illustrates logs displayed in the serial console during a Wi-Fi commissioning process.

Change the Default Settings

By Using the Prompt

By default the application starts by setting up a SoftAP which has hardcoded name. If you want to change the application behavior and directly start as a Station or if you want to start a SoftAP with a different name, a first solution is to press Enter within the 5 seconds after the microcontroller boot to start the prompt. The prompt allows to start in the desired mode and to select the Wi-Fi information (SSID, Passkey and Security mode). Note that this solution is not persistent to reboots or resets.

By Editing and Recompiling the Project

Compared to the previous method, this method is persistent to reboots or resets. The default settings, especially the settings related to the SoftAP (SSID, Passkey, Security mode and IP address) are defined in the lwip_micriumos.h file. You can change the default settings by editing this file, making the needed changes and recompiling the project.

Enable the Low Power Feature

The project file of the example provides a configuration enabling the low power on both the MCU and the WF200 chip. Either directly flash the provided binary or select the configuration in Simplicity Studio 4, build the project and flash the device with the generated binary.

You can refer to the AN1219: Power Consumption Measurement Setup and Results on WF(M)200 document to perform measurements on the WF(M)200 chip. Simplicity Studio 4 also provides the Energy Profiler tool, this tool allows to measure the current consumption of a Silicon Labs Starter Kit. The measures being made by the Starter Kit hardware, keep in mind that it is less accurate than a dedicated instrument, nevertheless it provides an idea of the current consumption quickly and easily. For more information about the Energy Profiler, please refer to UG343: Multi-Node Energy Profiler User’s Guide .

Notes:

Modify the Webpage

The Webpage sources are provided with the GitHub example in the src/lwip_host/webpage/fs folder when the project imported in Simplicity Studio 4. Notice that it is a symbolic link, the real location on your computer in the cloned repository is Examples/SiliconLabs/commissioning/webpage .

Follow the procedure below modify the webpage:

  1. Edit and modify the index.shtml file to fit your needs. Keep in mind that all changes can be reverted thanks to the Git versioning. Tip: Another IDE (e.g. VS Code, Atom, ...) can be used to preview the page while changes are made.
  2. Execute the makefsdata.exe or use the makefsdata provided by LwIP inside the SDK (location: util/third_party/lwip/lwip/src/apps/http/makefsdata).
  3. Rename the generated file fsdata.c into httpfsdata.c .
  4. Edit the file and remove include pragmas except #include "lwip/def.h" .
  5. Rebuild the project and flash the device.

Debugging Tools

GDB

The toolchain provided with Simplicity Studio 4 contains a compiler, a linker, all you need to build a project, and it also contains a debugger. This debugger, called gdb, allows you to walk into the program step by step, to set breakpoints, to access the MCU memory and registers, ... For more information about how to use the debugger inside Simplicity Studio 4, please refer to the section 4. Debugger inside the AN0822: Simplicity Studio™ User's Guide .

Tip: Before starting a debug session, disable the project optimizations by selecting None from the Optimization Level list in the section [Optimization] of [Tools Settings] tab from the Project properties (Project->Properties->C/C++ Build->Settings). By default the project is built using the highest optimization setting to have the highest Wi-Fi performances, making the debug experience painful since the instructions are reorganized, so the program will give the impression not to execute linearly.

Additional Logs

Always with the aim to have the highest possible Wi-Fi performances, only few logs are enabled and they are related to actions happening times to times. Nevertheless, having more logs is often good to track a bug or better understand a program behavior. In that purpose LwIP provides logs in each feature of the stack. These logs are disabled by default but can be enabled by editing the lwipopts.h file of the project. The file purpose is to configure the stack IP, like the features enabled or disabled.

To enable logs related to a specific feature:

  1. Find the associated define in the feature sources. The define name ends with _DEBUG , like HTTP_DEBUG, MQTT_DEBUG, TCP_DEBUG, ...
  2. Open the lwipopts.h file located in the lwip_host folder inside the project.
  3. Enable the global debug define LWIP_DEBUG in the top of the file.
  4. Enable the feature logs by adding the feature define inside the file and enabling it.

SEGGER SystemView

SEGGER SystemView is a powerful tool allowing to capture all the events (Task switching, Mutex/Semaphore acquisition and release, ...) in a Real-Time Operating System (RTOS) which is particularly helpful to define tasks priorities or to track a behavior leading to a Dead Lock. This tool supports Micrium OS and is provided free of charge with Simplicity Studio, it can be installed from the Simplicity Installation Manager by selecting the [Package Manager] option and the [Tools] tab, then look for the SEGGER SystemView Integration tool and install it. For more information about how to use SEGGER SystemView with Micrium OS, please refer to this documentation .

Optimization Considerations

This section describes steps to increase the throughput while keeping a minimum footprint necessary for your application. The first portion of this document describes the recommended tools. The second portion describes the firmware changes necessary to tweak the performance.

Optimization Tools

iPerf

iPerf is a well-known tool used to measure the throughput on an IP link. This example starts a TCP Server for iPerf testing by default, allowing you to check the throughput after tweaking the program configuration and see the impact. When enabled, the TCP Server for iPerf will be listening for incoming connections at any time. The method to start an iPerf test is dependent on the platform you are using to run the iPerf client: 

iperf -c 10.10.0.1

You simply need to issue this command as illustrated in the following image:

Micrium OS µC/Probe

Micrium provides the µC/Probe tool free of charge. This tool allows to watch in a graphical manner a program execution, like variables values, statistics, ... A dashboard for this tool is provided with the GitHub example, in the purpose of tracking in run-time the Micrium OS statistics, like the CPU and stack usages. It can also be used on the SDK example by retrieving this file. Note that the tool can also be used with the SDK example by retrieving the dashboard from the GitHub example and copying it inside your project.

To enable the visualization, make sure that the following defines are enabled inside the cfg/os_cfg.h file: 

#define OS_CFG_DBG_EN             DEF_ENABLED

#define OS_CFG_STAT_TASK_EN       DEF_ENABLED
#define OS_CFG_TASK_PROFILE_EN    DEF_ENABLED

Optimization Settings

Compiler Optimization

Open the Project’s Compiler Settings and set the Compiler Optimization level to: [Optimize most (-O3)] as shown in the image below. This optimization level will ensure the highest performances associated with a smaller binary.

Micrium OS Configuration

Debugging Configuration

Checks are done inside the Kernel to ensure the action previously done was successful. There can be a lot of checks and if the program behaves without triggering assertions (enabled by default) then it can be considered to disable all (or some of) the Kernel modules to see if it improves the performances. This can be done by editing the configuration file rtos_cfg.h and disabling the API argument check assertions and error logging by setting the following option: 

#define  RTOS_CFG_ASSERT_DBG_ARG_CHK_EXT_MASK            RTOS_CFG_MODULE_NONE

Following the same idea, the Kernel Logs can also be disabled by setting the following option: 

#define  RTOS_CFG_LOG_EN                                 DEF_DISABLED

The error code extended debugging information can also be disabled inside the configuration file rtos_err_cfg.h by setting the following options: 

#define  RTOS_ERR_CFG_EXT_EN                             DEF_DISABLED

#define  RTOS_ERR_CFG_STR_EN                             DEF_DISABLED
Runtime Statistics

Runtime statistics are set by default in the kernel, they can be disabled by editing the configuration file os_cfg.h and disable the kernel runtime statistics as follows: 

#define  OS_CFG_STAT_TASK EN                             DEF_DISABLED

#define  OS_CFG_TASK_PROFILE_EN                          DEF_DISABLED

LwIP Configuration

LwIP is an IP stack providing a great granularity to tweak the configuration and reach the best performances. This configuration can be modified by editing the lwipopts.h file located in the lwip_host folder inside the project. The dedicated Maximizing throughput article will help you focus on the main variables to reach the highest performances.

Enabling the LwIP statistics is particularly helpful to dimension the different memory pools. The statistics are enabled as follows in the lwipopts.h file. 

#define  LWIP_STATS                                      1
#define  LWIP_STATS_DISPLAY                              1

This allows to output the statistics in the console by adding a call to the function stats_display() in your application.

Wi-Fi FMAC Driver Documentation

For your own application development or for more information about the Wi-Fi FMAC Driver, please refer to the documentation .

Troubleshooting

Connecting the WGM160P Wi-Fi Module Radio Board to your Wireless Network is a complex process. If any of the steps in the process is not done correctly, failure can occur. This section describes a few basic steps you can take to troubleshoot this demo.

Check the Debugging Messages from a Serial Terminal

Open a serial terminal as described in the third step of the section Start the Example .

Check the Hardware Connections

Check the boards connection to ensure that the WGM160P Wi-Fi Module Radio Board is inserted tightly into the Silicon Labs Wireless STK baseboard and make sure that the power source switche of the Silicon Labs Wireless STK baseboard is in the correct position, as described in section Setup your Kit .

Verify Wi-Fi Access Point Settings

Use your Wi-Fi router’s (i.e., AP) administrative GUI to verify network settings for the wireless network Service Set Identifier (SSID) to which your WGM160P Wi-Fi Module is trying to connect. Locate the SSID that you are troubleshooting. On a basic Wi-Fi router, there may be just one SSID, or one for each radio band (2.4 GHz and 5 GHz). Identify the IP subnet assigned to that SSID. Upon successful connection, your WGM160P Wi-Fi Module should receive a local IP address from this subnet. Identify the Wi-Fi router’s local IP address that should be reachable through this subnet. Check your Wi-Fi router's events log or status GUI to verify that an IP address from this subnet is assigned to your WGM160P Wi-Fi Module when it connects. After you have all the above information, ensure that it matches the settings in your embedded application, as described in the section Change the Default Settings .

Verify Network Connection with Ping

After your WGM160P Wi-Fi Module has a valid IP address, use ping to verify network connectivity. Ping your WGM160P Wi-Fi Module from another station or from your Wi-Fi router.

Check Wireless-Specific Issues

If your WGM160P Wi-Fi Module still can't connect, get a valid IP address or ping your Wi-Fi router. Then, it's time to consider wireless-specific problems. The Wi-Fi AP or router and WGM160P Wi-Fi Module must use compatible 802.11 standards and the same network name (SSID). Use your AP or router's admin GUI to view WLAN settings and compare them to your embedded application's wireless connection parameters. Run the scan command in the Serial Console and verify that your Wi-Fi AP or Router is displayed in the list. If your SSID does not appear in the WF200's Available Networks list, enable SSID broadcasts on your AP or router. Be sure to match the SSID exactly, including capitalization.

Look for a Security Mismatch

If your WGM160P Wi-Fi Module and Wi-Fi AP or router can hear each other but still cannot connect or exchange traffic, look for a security mismatch.

Configure the Wi-Fi AP or Router to one of the security modes the WF200 supports: Open, WEP, WPA, WPA2 or WPA3. Compare your Wi-Fi AP or router's WLAN security settings to your embedded application's Wi-Fi connection properties to match them, as described in the section Change the Default Settings .

Check Intermittent Network Connectivity Issues

Finally, if your WGM160P Wi-Fi Module connects and pings successfully, but encounters intermittent network connectivity problems (e.g., some pings work, some fail), you may be experiencing poor signal strength, RF interference, or if the demo has been modified, a software-related problem.

If the demo has been modified, such as by adding an additional task or modifying task priorities, see the Micrium OS Kernel Troubleshooting Guide at: https://doc.micrium.com/display/OSUM50700/Kernel+Troubleshooting

Otherwise, disconnect your Wi-Fi AP or router from power and wait at least 30 seconds before restoring power.