Migrating from WiSeConnect SDK v4.0.2 to v4.1.0#

Overview#

This guide describes how to update an existing application from WiSeConnect™ SDK v4.0.2 to v4.1.0.

Version 4.1.0 introduces naming and file changes compared to v4.0.2 to improve consistency and API usability. As a result, migration requires updating the affected names throughout the application.

Migration Steps#

Perform these steps to convert a WiSeConnect SDK v4.0.2 application to a v4.1.0 application:

Open your existing application project in Simplicity Studio.
In the project files, update the v4.0.2 deprecated content with the corresponding v4.1.0 equivalents. This step is recommended because of deprecation of the specified APIs and AT commands. If you intend to upgrade to future releases, we recommend that you make these changes before Dec 2027, the end of the deprecation period for this release.

CMSIS Upgrade (5.8.0 to 6.2)#

WiSeConnect SDK v4.1.0 updates CMSIS from 5.8.0 to 6.2. In CMSIS 6.2, the reserved field in the osThreadAttr_t structure is replaced by affinity_mask. During migration from any previous version to 4.1.0, you may experience compilation issues if your application still references reserved, as the structure member is no longer available. Update each instance of reserved to affinity_mask in your application code. Refer to Simplicity SDK Version 2026.6.0 - Release Notes for more details.

Deprecated APIs#

Note: The following elements are applicable to both NCP and SoC modes.

Note: Starting from WC-4.1.0, we recommend using the new versions of APIs/Structures/Macros to ensure compatibility with future releases.


Module	v4.0.2 [Deprecated]	v4.1.0 [New]
Wi-Fi	`sl_wifi_set_11ax_config`	`sl_wifi_set_11ax_config_v2`
Network Stack	`sl_net_dns_resolve_hostname`	`sl_net_dns_resolve_hostname_v2`
Wi-Fi	`sl_wifi_target_wake_time_auto_selection`	`sl_wifi_target_wake_time_auto_selection_v2`
Wi-Fi	`sl_wifi_twt_selection_t`	`sl_wifi_twt_selection_v2_t`
Wi-Fi	`sl_wifi_filter_broadcast`	`sl_wifi_set_groupcast_filter_config` and `sl_wifi_set_beacon_drop_threshold`
Wi-Fi	`sl_wifi_configure_multicast_filter`	`sl_wifi_set_groupcast_filter_config` and the multicast IP allowlist APIs (`sl_wifi_allowlist_mcast_add_ip`, `sl_wifi_allowlist_mcast_remove_ip`, `sl_wifi_allowlist_mcast_remove_all`)
Wi-Fi	`sl_si91x_configure_timeout`	`sl_wifi_configure_timeout` and `sl_wifi_get_timeout`
Wi-Fi	`sl_si91x_timeout_type_t`	`sl_wifi_timeout_type_t`
Platform	`sl_si91x_power_manager_sleep`	Power Manager service with tickless idle (do not call directly in RTOS applications)
Platform	`sl_si91x_power_manager_standby`	Tickless idle and PS requirement APIs (not for direct application use under RTOS)
Platform	`dummy_printf()`	SL Log / `sl_log_helper.h`

Deprecated AT Command#


Module	v4.0.2 [Deprecated]	v4.1.0 [New]
Wi-Fi	`at+wifi-net-info?`	`at+net-info=<interface>`

Deprecated Components#

The following components are deprecated in the WiSeConnect SDK starting from the v4.1.0 release. It is recommended to remove these components from the application .slcp files:

sl_si91x_basic_buffers
sl_si91x_mem_pool_buffers
sl_si91x_mem_pool_buffers_with_quota

These components are replaced by the sli_buffer_manager component, which is automatically included by the sl_si91x_wireless component. Explicit inclusion in the application .slcp files is no longer required.

Notes on Deprecation Warnings#

For information about deprecation warnings in WiSeConnect SDK v4.1.0, see SL_DEPRECATED_API_WISECONNECT_4_1.
For information on suppressing deprecation warnings in WiSeConnect SDK v4.1.0, see SL_SUPPRESS_DEPRECATION_WARNINGS_WISECONNECT_4_1.

WiSeConnect SDK v4.1.0 introduces a new internal SDK thread called the HAL thread. If your application customizes WLAN thread priorities, you must review and update them as described in the section below.

New HAL Thread and Required Priority Order#

With the addition of the HAL thread, the SDK now manages three WLAN threads. Their default priorities in v4.1.0 are:

Event engine thread: osPriorityRealtime2 (first highest priority)
HAL thread (new in v4.1.0): osPriorityRealtime1 (second highest priority)
Command engine thread: osPriorityRealtime (third highest priority)

Note: A higher osPriority value indicates a higher priority. For example, osPriorityRealtime2 is higher than osPriorityRealtime1.

Action Required if You Override the Default Thread Priorities#

If your application overrides the default WLAN thread priorities using the preprocessor macros SL_WLAN_COMMAND_ENGINE_THREAD_PRIORITY or SL_WLAN_EVENT_THREAD_PRIORITY, you must explicitly set the HAL thread priority using the new macro SL_WLAN_HAL_THREAD_PRIORITY.

When assigning custom priorities, the following relative order must be preserved (from highest to lowest priority): Event engine thread > HAL thread > Command engine thread

Important: If this priority order is not maintained, the sl_net_init() and sl_wifi_init() APIs will fail and return the SL_STATUS_INVALID_CONFIGURATION error.