Recommended Settings in WiSeConnect™ SDK#

This guide consolidates recommendations for both SoC and NCP operation modes using the WiSeConnect™ SDK.

System#

SoC Only#

  • The current revision of SiWx917 has:

    • RAM memory of 672k bytes which can be shared between NWP and M4 processors in SoC mode.

    • The below configurations are applicable in SoC mode and can be configured based on the application requirement. EXT_FEAT_480K_M4SS_192K is the default configuration, based on requirement EXT_FEAT_480K_M4SS_192K configuration is selected for SoC mode multi-protocol examples.

      • EXT_FEAT_480K_M4SS_192K - This mode configures NWP with 480k and M4 with 192K bytes of memory

      • EXT_FEAT_416K_M4SS_256K - This mode configures NWP with 416k and M4 with 256K bytes of memory

      • EXT_FEAT_352K_M4SS_320K - This mode configures NWP with 352k and M4 with 320K bytes of memory

    • SoC mode should not use 672k_M4SS_0K memory configuration.

  • There are 2 Versions of Pro-Kits/Radio boards. Si917-6031A based on Si917-4338A (Rev A01 - A11) and SiWx917-6031A based on SiWx917-4338A (Rev A12-A14). To get optimal power numbers, enable macro SL_SI91X_ENABLE_LOWPWR_RET_LDO pre-processor define for ICs or while using SiWx917-6031A Pro-kit, SiWx917-4338A version of boards. This macro should be disabled for earlier variants of the board (Si917-6031A, Si917-4338A).

  • With RAM configuration (EXT_FEAT_352K_M4SS_320K), only 352K memory is available to NWP which limits the features supported, Recommended to enable EXT_FEAT_416K_M4SS_256K in Wi-Fi + BLE Multi protocol mode to enable more Network features.

  • For EXT_FEAT_416K_M4SS_256K and EXT_FEAT_480K_M4SS_192K memory configurations, it is recommended to retain both NWP and M4 RAMs in power save.

NCP Only#

  • Memory configuration for NCP mode is 672K_M4SS_0K

  • Set the following recommended FreeRTOS configuration in FreeRTOSConfig.h:

    • configTIMER_TASK_PRIORITY to 55

    • configTOTAL_HEAP_SIZE to 51200

    • configUSE_POSIX_ERRNO to 1

SoC and NCP#

  • Set the recommended Power Save Profile (PSP) type to Enhanced Max PSP.

Thread Priority Guidelines#

  • Define the preprocessor macro SL_WLAN_EVENT_THREAD_PRIORITY with a high thread priority to ensure timely handling of events received from the NWP. Default: osPriorityRealtime1

  • Define the preprocessor macro SL_WLAN_COMMAND_ENGINE_THREAD_PRIORITY to a priority level just below that of the Event thread. Default: osPriorityRealtime

  • If application threads are assigned higher priorities than Event or Command Engine threads, they must be explicitly designed to yield, delay, or block as necessary. Doing so ensures that Event and Command Engine threads that are critical to system performance can execute without experiencing undue latency.

  • It is important to prevent thread starvation, a condition where higher-priority application threads interfere with the timely execution of Event and Command Engine threads.

Wi-Fi / Network Stack#

SoC and NCP#

  • Randomize the client port if using rapid connect/disconnect of the MQTT session on the same client port with the power save.

  • It is recommended to set region code as IGNORE_REGION in boot configurations for SIWG917Y module boards except for PER mode.

  • MDNS works best with the DTIM-based power save method. Performance issues could be observed with the Listen interval-based power save method due to multicast packet loss.

  • Enable BIT(10) - SL_SI91X_FEAT_SSL_HIGH_STREAMING_BIT in feature bitmap to increase TLS_Rx throughputs.

  • In IPv6 mode, MDNS will use the Link-local address if a unicast global address isn't set, and will use the unicast global address when its configured.

  • It is recommended to enable SL_SI91X_EXT_TCP_IP_WAIT_FOR_SOCKET_CLOSE BIT(16) of the 'Extended TCP IP Feature' bit map in the opermode command for all Wi-Fi Socket operations from the host to ensure graceful handling during asynchronous closures from the peer.

  • For high throughputs, it is recommended to enable BIT(2) - SL_SI91X_FEAT_AGGREGATION of feature_bit_map in opermode.

  • Users can enable SL_SI91X_EXT_TCP_IP_SSL_16K_RECORD in 'Extended TCP IP Feature' bit map in opermode for (HTTPS server) supporting 16k record

  • TWT

    • Recommendation is to use sl_wifi_target_wake_time_auto_selection() API for all TWT applications

    • It is recommended to issue iTWT setup command once IP assignment, TCP connection, application specific socket connections are done

    • When using sl_wifi_enable_target_wake_time API, increase TCP / ARP Timeouts at the remote side depending upon the configured TWT interval configured. It's highly recommended to use sl_wifi_target_wake_time_auto_selection() as an alternative

    • In case of TWT in CoEx mode, when using sl_wifi_enable_target_wake_time API, use TWT wake duration <= 16 ms and TWT wake interval >= 1 sec. If wake duration > 16 ms or TWT wake interval < 1sec, there might be performance issues

    • For iTWT GTK interval in AP should be configured to max possible value or zero. If GTK interval is not configurable on AP side, recommended TWT interval (in case of sl_wifi_enable_target_wake_time API) or RX Latency (in case of sl_wifi_target_wake_time_auto_selection API) is less than 4sec

    • When sl_wifi_enable_target_wake_time API is used, configuring TWT Wake interval beyond 1 min might lead to disconnections from the AP. Recommended to use TWT wake interval of less than or equal to 1 min

    • When using sl_wifi_enable_target_wake_time API, it is recommended to set missed_beacon_count of sl_wifi_set_advanced_client_configuration API greater than 2 times of the configured TWT Interval.

    • DUT keepalive should be configured aligned with AP keepalive in TWT modes.

  • Disable power save for high throughput applications or use FAST PSP power save mode as per application requirement

  • The application needs to ensure that it sets RTC with the correct timestamp before establishing the SSL/EAP connection.

  • The minimum timeout value should not be less than 1 second for socket select and socket receive calls.

  • Please refer Keep alive intervals supported by MQTT broker and configure keep alive interval values accordingly.

  • The minimum keep alive interval value recommended for embedded MQTT is 10 Seconds.

  • Disable power save and suspend any active TWT sessions before triggering HTTP OTAF.

  • Randomize the client port if using rapid socket connect/disconnect.

  • Recommended to configure VAP_ID properly for Si91x STA and AP using sl_si91x_setsockopt_async(), in case of data transfer.

  • Recommended to use valid length (<= 202 bytes) for topic to be published while using Embedded MQTT, else it leads to return wrong error code (0x21).

  • In concurrent mode with dual IP, it is advised to bring up STA first (IP configuration) and AP later

  • It is recommended to configure Tx, Rx, Global buffer pool ratio in the buffer config command for all Wi-Fi Socket operations from the host

  • It is recommended to use "TCP exponential backoff" configuration for congested channels

  • It is recommended is to disable broadcast filter during TCP connection to avoid ARP resolution issues

  • To avoid IOP issues, it is recommended to disable power save before Wi-Fi connection

  • An intermediate CA should be a trusted CA, provided it is not a self-signed certificate. To be considered as a trusted CA, the KeyUsage field must be explicitly configured while generating the certificate

  • It is recommended to enable RSI_REJOIN_FIRST_TIME_RETRY to minimize join failures, especially in scenarios such as abnormal connection termination caused by a module reset or power failures.

  • The recommended payload size for embedded MQTT Publish messages is 1 kB.

  • It is recommended to set the TCP retransmission count value to 30 or higher to prevent disconnection during rejoin attempts.

  • Disable power save mode before establishing a TCP connection for the NCP-UART interface.

  • To configure the region code (also known as regulatory domain or country code), assign the appropriate value from the sl_wifi_region_code_t enumeration to the region_code field in the sl_wifi_device_configuration_t structure.

    Note: Its use and behavior may be restricted depending on the device certification and operational mode. Please refer sl_si91x_set_device_region.

  • For AP mode, configure default region-specific regulatory settings in the sl_wifi_region_db_config.h file

BLE#

SoC and NCP#

  • In BLE, the recommended range of Connection Interval in Power Save (BLE Only) - 100 ms to 1.28 s.

  • In BLE, during Connection, the configuration of Scan Interval and Scan Window with the same value is not recommended. The suggested ratio of Scan Window to Scan Interval is 3:4.

  • In BLE, when the scan window duration exceeds the power save command timeout (i.e., 3 seconds), it is recommended to first issue the power save command, followed by the BLE start scanning command.

  • In BLE, if a device is acting as Central, the scan window (in set_scan_params and create_connection commands) must be less than the existing Connection Interval. The suggested ratio of Scan Window to Connection Interval is 2:3.

  • In BLE mode, if scanning and advertising are in progress on the SiWx91x module and it subsequently gets connected, the following occurs:

    • Central Role: Scanning stops.

    • Peripheral Role: Advertising stops.

    To establish a connection with another peripheral or central device, the application must issue a command to restart advertising and scanning.

  • To protect sensitive information and mitigate the risk of passive snooping, it is recommended to enforce encryption prior to any data transmission over BLE connections. BLE allows optional encryption, and if it is not enabled, attackers can easily eavesdrop on data traffic using sniffer tools. This exposes all user data over the connection to unauthorized interception, posing a major privacy risk.

  • To prevent sensitive information leakage and device impersonation, it is recommended to enforce the Secure Connections pairing mode on BLE devices. BLE Legacy Pairing is vulnerable to passive eavesdropping, allowing attackers to derive encryption keys and decrypt all future communications between paired devices. This can lead to spoofing, tampering, and elevation of privilege. Most modern devices support Secure Connections, so enforcing this mode typically does not cause interoperability issues.

  • To protect against spoofing, tampering, and unauthorized data access, it is recommended to use authenticated pairing methods whenever device I/O capabilities allow user interactions, such as PIN entry or numeric comparison. The Just Works pairing method lacks protection against man-in-the-middle (MITM) attacks, enabling attackers to intercept and manipulate encrypted communications between devices. Authenticated pairing methods such as Numeric Comparison (where users verify matching codes on both devices) or Passkey Entry (where users enter a passkey) significantly reduce this risk by introducing user interaction and verifying device identities during the pairing process.

  • To prevent spoofing and unauthorized data manipulation, it is recommended to immediately encrypt the connection when reconnecting to a bonded device. BLE allows easy spoofing of device addresses before encryption is established, making it difficult to verify device identity. If encryption is delayed until accessing protected GATT characteristics, a spoofed server may respond with misleading data, potentially affecting client behavior. Early encryption ensures the client can authenticate the server using the stored LTK, preventing impersonation and tampering.

  • To prevent unauthorized access through spoofing and replay attacks, it is recommended to avoid using RSSI as the sole method for proximity-based authentication in BLE systems. Relay attacks exploit the ability to record and replay BLE packets in different physical locations, bypassing proximity-based security mechanisms. This is especially critical in applications such as smart locks or vehicles, where access should depend on close physical presence. The Bluetooth specification advises against relying on RSSI for range validation due to its vulnerability to such attacks.

  • To prevent spoofing and unauthorized authentication, it is recommended to reject authentication evidence that matches previously sent data and to generate a fresh random number for each authentication attempt. Reflection attacks exploit the reuse of authentication proofs and random data, allowing an attacker to falsely appear as possessing a secret without actually knowing it. This can compromise encrypted connections and enable data manipulation. Ensuring uniqueness in each authentication exchange helps mitigate this risk.

  • To protect against tampering, denial of service, and information disclosure, it is recommended to validate all incoming messages and perform fuzz testing on the BLE protocol stack. Protocol-breaking attacks involve sending malformed or non-standard data to a device to exploit vulnerabilities in its protocol handling. These attacks can lead to device crashes, unauthorized data access, or even remote code execution. Rigorous input validation and fuzz testing help ensure the stack can safely handle unexpected or invalid inputs.

  • To minimize the impact of denial of service (DoS) attacks, it is important to recognize that Bluetooth is inherently vulnerable to jamming and interference due to its wireless nature. These attacks can temporarily disable the Bluetooth interface or drain device battery. While such attacks are generally moderate in severity and proximity-dependent, they can be easily executed using simple equipment. Frequency-hopping and interference detection mechanisms are handled in firmware so moving out of range can help mitigate this risk.

  • To prevent tampering, unauthorized access, and privilege escalation, it is recommended to restrict physical access and secure communication channels between host MCU and SiWx917 in NCP mode. The wifisdk protocol is unencrypted, making it vulnerable to eavesdropping and command injection. An attacker with physical access can exploit this to gain unauthorized control over the BLE stack. Implementing encryption and authentication for wifisdk communication helps mitigate this risk.

  • To prevent information disclosure and unauthorized decryption of encrypted connections, it is recommended to use encrypted storage for bonding keys and never expose plain keys through the wifisdk interface. Devices that store bonding-related encryption keys without protection are vulnerable to attacks where keys can be read via wifisdk commands. This allows attackers with physical access to decrypt communications and manipulate data. Additionally, all debug interfaces should be disabled in production devices to reduce exposure.

Multi-protocol#

SoC and NCP#

  • For concurrent Wi-Fi + BLE, and while a Wi-Fi connection is active, we recommend setting the ratio of the BLE scan window to BLE scan interval to 1:3 or 1:4.

Wi-Fi + BLE Advertising#

  • All standard advertising intervals are supported. When more than two BLE connections are active, configure the BLE advertising interval to 211.25 milliseconds.

  • As Wi-Fi throughput is increased, a slight difference in on-air advertisements compared to configured intervals may be observed.

  • BLE advertising is skipped if the advertising interval collides with Wi-Fi activity.

Wi-Fi + BLE scanning#

  • All standard scan intervals are supported. For better scan results, we recommend setting the ratio of the BLE scan window to BLE scan interval to 1:3 or 1:4.

  • BLE scanning will be stopped for intervals that collide with Wi-Fi activity.

Wi-Fi + BLE Central/Peripheral Connections#

  • For a stable connection, use optimal connection intervals and max supervision timeout in the presence of Wi-Fi activity.

Wi-Fi + BLE Central/Peripheral Data Transfer#

  • To ensure optimal BLE throughput, it is recommended to use optimal connection intervals along with the maximum supervision timeout.

SoC Only#

  • We recommend using the SOC clock only up to 120 MHz (SL_SI91X_CUSTOM_FEAT_SOC_CLK_CONFIG_120MHZ). At 160 MHz, BLE disconnections are observed while running WLAN + BLE.