https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6368096Tue, 02 Jun 2026 22:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7e28d352-c360-4e71-9cc8-90ea9b8d16a3Josh SmithHi Fenil, Apologies as the way the conf answer was explained is a bit confusing to me. Are you saying you are using CC3351 IC .bin on the device or CC3351MOD.bin on the device I am asking because the default IL should not be 0. It should be set to 0c. From the combination of your S21 and the default insertion loss of the module, I would expect roughly ~ 2.75dB (16 in hexadecimal) of loss to be configured/typed into your unlimited conf. That way the device can accommodate for that loss and adjust the power accordingly to meet your desired power level. Another way we can check this is by using a BP-CC3351MOD(if you have one), load the .bin file you are using on your custom board(without IL modification) and measure the power. Send results here when you do. Joshhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1651593/cc3351-cc33xx-rtos-mcu-package-bundled-third-party-components-modifiedTue, 02 Jun 2026 16:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:72be7d44-c273-4cfa-944e-30e170e129a6Danilo A.Part Number: CC3351 Hi Team, Posting on behalf of our customer. I&#39;ll share this E2E post with our customer so he can reply when needed. I am currently working with CC3351 + STM32 using the CC33XX RTOS MCU Package R9. The MCU package includes third-party components for NimBLE and lwIP. According to the release notes included under each component directory, the versions are: - NimBLE: v1.7.0 - lwIP: 2.1.3 I would like to manage NimBLE and lwIP as upstream Git submodules in my project repository. However, I noticed that the sources included in the CC33XX RTOS MCU Package do not exactly match the corresponding upstream release tags. For NimBLE, the package appears to include changes from commits beyond the stated v1.7.0 release. For lwIP, the package appears to contain custom modifications, similar to what was discussed in the forum thread for the CC3551E SDK . Could you please clarify: 1. Does TI have a documented policy or recommendation for handling these third-party components? For example, should users treat the bundled NimBLE and lwIP sources as TI-validated snapshots, or is it expected that users may replace them with upstream releases? 2. Could replacing the bundled sources with the official upstream release tags, or upgrading to newer upstream versions, introduce compatibility issues with the CC33XX host drivers or firmware interface? Regards, DaniloCC3551Ebuilding automationCC3351https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642130/cc3551e-uart-driver-read-issue/6367638Tue, 02 Jun 2026 15:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e20c3db9-954a-4b8d-af0e-cf33955fa838BLiuHi Edward, Our development team is still investigating this, but I did have a new find on my end: /* * Copyright (c) 2020-2025, Texas Instruments Incorporated * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * * Neither the name of Texas Instruments Incorporated nor the names of * its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS &quot;AS IS&quot; * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include #include /* POSIX Header files */ #include /* Driver Header files */ #include #include /* Driver configuration */ #include &quot;ti_drivers_config.h&quot; static sem_t sem; static volatile size_t numBytesRead; /* * ======== callbackFxn ======== */ void callbackFxn(UART2_Handle handle, void *buffer, size_t count, void *userArg, int_fast16_t status) { if (status != UART2_STATUS_SUCCESS) { /* RX error occured in UART2_read() */ while (1) {} } numBytesRead = count; sem_post(&amp;sem); } /* * ======== mainThread ======== */ void *mainThread(void *arg0) { char input; const char echoPrompt[] = &quot;Echoing characters:\r\n&quot;; UART2_Handle uart; UART2_Params uartParams; int32_t semStatus; uint32_t status = UART2_STATUS_SUCCESS; /* Call driver init functions */ GPIO_init(); /* Configure the LED pin */ GPIO_setConfig(CONFIG_GPIO_LED_0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW); /* Create semaphore */ semStatus = sem_init(&amp;sem, 0, 0); if (semStatus != 0) { /* Error creating semaphore */ while (1) {} } /* Create a UART in CALLBACK read mode */ UART2_Params_init(&amp;uartParams); uartParams.readMode = UART2_Mode_CALLBACK; uartParams.readCallback = callbackFxn; // uartParams.baudRate = 115200; uartParams.baudRate = 1500000; uart = UART2_open(CONFIG_UART2_0, &amp;uartParams); if (uart == NULL) { /* UART2_open() failed */ while (1) {} } /* Turn on user LED to indicate successful initialization */ GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON); /* Pass NULL for bytesWritten since it&#39;s not used in this example */ UART2_write(uart, echoPrompt, sizeof(echoPrompt), NULL); /* Loop forever echoing */ while (1) { numBytesRead = 0; /* Pass NULL for bytesRead since it&#39;s not used in this example */ status = UART2_read(uart, &amp;input, 32, NULL); if (status != UART2_STATUS_SUCCESS) { /* UART2_read() failed */ while (1) {} } /* Do not write until read callback executes */ sem_wait(&amp;sem); usleep(1000); // killer input = 48 + numBytesRead; if (numBytesRead &gt; 0) { status = UART2_write(uart, &amp;input, 1, NULL); if (status != UART2_STATUS_SUCCESS) { /* UART2_write() failed */ while (1) {} } } } } In this project, the SYSCFG settings for the RX and TX ring buffer size are set to 32. At 115200 baud rate, bytes don&#39;t get stuck in the ring buffer; at 1500000 baud rate, the first iteration may look wrong, but the rest are accurate if you keep spamming the terminal with more than 32 characters. Of course, I noticed that after adding the sleep function, we are back to square one (hence labeled as &quot;killer&quot;). Is this something you can use for the time being?https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1651333/tusb4020bi-errata-document/6367402Tue, 02 Jun 2026 13:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:29de8146-c2e0-4be2-9360-6f2381efd3f9Brian ZhouHi Teja: we don&#39;t have errata document for TUSB4020B. Best Brianhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1647752/cc3135-relation-between-maxsleeptimems-and-region-on-5-ghz-network/6367401Tue, 02 Jun 2026 13:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9447cb6e-59ba-4b65-a3d3-5079ace425c0Aljaž KrašnaHi, Thanks for your efforts on this. Please keep me updated when there are any new developments. Regardshttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6367320Tue, 02 Jun 2026 12:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4fa9ff09-b8d0-4e19-b4c1-32074ba24df3Fenil LadaniHi Josh, [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6366312&quot;]Your conf lists the default insertion loss as 0dBm? The default insertion loss for 5GHz should be 1.5dBm since you are using the module which aligns with the results you sent me earlier. Can you confirm this? Can you double check you are using the CC3351MOD conf and not the CC3351 IC conf? You can use the &quot;Load&#39; option in Radio Tool&#39;s INI Composer Tool to load your bin and confirm.[/quote] Yes, I have used the &quot; cc33xx-conf-unlimited.bin &quot; for the test, i also checked the in unlimited.bin in INI Composer tool it set to 0x00 by default. Additionally we are using the CC3351MOD conf. [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6366312&quot;]Additionally, is it possible to provide an S21 measurement from module pad to SMA? I essentially want to see if there are any expected losses on your design at the higher frequency. The results you gathered are a bit higher than we expected and only seem to be at the higher frequencies so this would be good to check.[/quote] Yes, below is the S21 measurement. BR, Fenilhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1647752/cc3135-relation-between-maxsleeptimems-and-region-on-5-ghz-network/6367272Tue, 02 Jun 2026 10:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:71e71515-baa7-451c-a98c-a49d0fa5fb32Shlomi ItzhakHi, Everything I tried does not yield any stable workaround. Let me check internally. Regards, Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1636876/cc3220sf-cc3220sf-nwp-hangs-at-sl_start-after-sl_stop/6367268Tue, 02 Jun 2026 10:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0b036c9a-13e9-4dfb-8b6d-5a6d572a2e20Shlomi ItzhakHi, I don&#39;t see the immediate relation since this is during sl_stop(). This section in the log always looks OK. NWP waits for all operations to end and gracefully acknowledge to the host. What changes have been made that might affect this scenarios? for GSPI, are you using the default DMA channels? are there any other peripherals in your system that uses DMA channels that are different than the default? Regards, Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1636876/cc3220sf-cc3220sf-nwp-hangs-at-sl_start-after-sl_stop/6367202Tue, 02 Jun 2026 09:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e05cd0b0-4a77-4ce4-abc7-7e55adac51c4Erik AnderssonCould it possibly be related to this? RE: CC3220SF: NwpPowerOff timeout Strange behaviour at NWP shutdownhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1636876/cc3220sf-cc3220sf-nwp-hangs-at-sl_start-after-sl_stop/6367124Tue, 02 Jun 2026 08:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1fecc413-c4ef-42e3-9e7a-48d50b02aedaShlomi ItzhakHi, The only hint I could find is the other SPI (GSPI) since I know there is a fix that increases the LSPI priority to high compared to the GSPI to prevent the LSPI to be served in rare conditions. But if you are using the latest 3.22, it should be OK. At least from the logs, the NWP seems to be working fine. Since I do not see any command reaching the NWP after the station role setting, I assume the host side is getting stuck since for the host it seems like the NWP is stuck/non-responsive. You also mentioned that when PHY_CAL_MODE is set to 0 (normal mode) it happens but when it is set to 1 (triggered mode), it does not. The main difference is that in triggered mode, there is no calibration when getting out of nReset. Again, on the current NWP I can see that the calibration file is fetched from the file system and used and that there is no re-calibration taking place (not required since it is getting out of nHib). So it is hard to tell what could cause the system to freeze after a while if you are using the latest SP. Regards, Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649299/cc3235sf-cc3235sf-en301-893-5g-mode-adaptivity-test-failed/6367021Tue, 02 Jun 2026 07:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9d20120a-d838-4354-b40e-3206f250c426Ethan Chanhi, Jonathan, We verified that the device can successfully scan for and connect to the 5 GHz AP using the Network Terminal application. However, when testing with the CPERF tool, multiple scan attempts using the -n 50 option failed to detect the AP, and direct connection attempts also resulted in failure. In addition, during our laboratory testing, we observed that the EUT triggers the Adaptivity mechanism after detecting the interference signal. However, instead of immediately ceasing transmission, it continues to send short control packets for approximately 2 seconds before becoming completely silent. These short control transmissions are included in the test measurement and consequently lead to a test failure. Could you explain why the EUT does not immediately stop all transmissions once interference is detected and the Adaptivity mechanism is triggered? Regards, Ethanhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1651333/tusb4020bi-errata-documentTue, 02 Jun 2026 06:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0faf5f54-d02b-4d24-8070-230133abe887Teja VelagapudiPart Number: TUSB4020BI Please provide ERRATA document of TUSB4020BIPHPR.TUSB4020BIhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1570354/cc3351-customized-packet-filter-cannot-be-implemented-with-wolan-pattern/6366343Mon, 01 Jun 2026 20:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:557e83b1-1987-48cf-bbb3-6d23a4eacd97Sabeeh Khan1Hello Jihu, Yes we should be able to provide an early release by this month with this implementation.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6366312Mon, 01 Jun 2026 20:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:031f921b-5b4a-4852-bc76-ab89ff50b6b2Josh SmithHi Fenil, [quote userid=&quot;630773&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6365708&quot;]Yes we have measured the insertion loss for 5GHz it is around 1dB to 1.4dB, Yet we have not set the insertion loss for the conf.bin file. We have tested with default 0dB loss.[/quote] Your conf lists the default insertion loss as 0dBm? The default insertion loss for 5GHz should be 1.5dBm since you are using the module which aligns with the results you sent me earlier. Can you confirm this? Can you double check you are using the CC3351MOD conf and not the CC3351 IC conf? You can use the &quot;Load&#39; option in Radio Tool&#39;s INI Composer Tool to load your bin and confirm. [quote userid=&quot;630773&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6365708&quot;]Lastly, optimal performance of the PA is at 30% duty cycle. Can you ensure you are transmitting at 30% DC?[/quote] You can adjust DC by changing you packet size and delay. Here is a graphic that can give you some baseline to refer to: Additionally, is it possible to provide an S21 measurement from module pad to SMA? I essentially want to see if there are any expected losses on your design at the higher frequency. The results you gathered are a bit higher than we expected and only seem to be at the higher frequencies so this would be good to check. Best, Joshhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1650548/cc3551e-how-to-modify-the-image-version-of-bl2-and-ti_wireless_fw/6366273Mon, 01 Jun 2026 19:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:22993d06-403b-4198-90d8-c80db8b94768BLiuHi, I have a solution to experiment with OTA regarding BL2 and wireless firmware; you correctly point out that these version numbers cannot be manipulated, and this is because TI sets them. However, different SDK versions will have used different BL2 and WFw images so you can look for one with a different version image and try to perform OTA.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1651123/cc3351mod-cc3351-firmware-crashMon, 01 Jun 2026 13:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:10206069-b949-4714-8581-f8dfc7b791afDominik HoellmuellerPart Number: CC3351MOD Other Parts Discussed in Thread: CC3351 Hi, I was on vacation and it seems the original thread was closed. I have downloaded the new wifitoolbox and the firmware for the chip and the issue I describe in the orignial post still persists. Regarding the questions you asked me 1. Could you please check the USB-UART connection? Making sure that the LOGGER pin on the cc3351 is connected to the RX pin of your UART-USB cable? -&gt; I replaced the USB-UART and also checked with putty, i see binary data come in. 2. Perhaps you can use a multimeter or logic analyzer to just triple check that there is actually a signal being outputted from the LOGGER pin. -&gt; I uses an oscilloscope to check the signal it looks fine to me. 3. Could you try to remove the &#39;wlogger_dissector.lua&#39; from C:\Program Files\Wireshark\plugins, and then re-boot the Simplelink WiFi Toolbox? The Logger Tool will then provide a command for you to input into a powershell with admin access. -&gt; Also did this but did not help Would a raw log help in this case? I tried to decode it locally but the proccess never completed. Any further suggestions would be appreciated. Best, DominikWireless InfrastructureCC3351CC3351MODhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6365708Mon, 01 Jun 2026 13:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cdbcfbf9-772e-4274-8e2d-b76f51d84305Fenil LadaniHi Josh, [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6362834&quot;]Have you ensured to measure the insertion loss for 5GHz on your custom board? Even using the unlimited INI this needs to be accounted for in the conf.bin file.[/quote] Yes we have measured the insertion loss for 5GHz it is around 1dB to 1.4dB, Yet we have not set the insertion loss for the conf.bin file. We have tested with default 0dB loss. [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6362834&quot;]Additionally, is this SU or TB? If TB, what RU allocation?[/quote] I have configured the 802.aaax SU mode during test. [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6362834&quot;]For 802.11ax, just ensuring you are using PHY rate MCS0 -MCS7 correct?[/quote] Yes, I am using the PHY rate MCS0-MCS7 only. [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649397/cc3351mod-calibrator-tool-commands-for-factory-calibration-mode-plt-mode/6362834&quot;]Lastly, optimal performance of the PA is at 30% duty cycle. Can you ensure you are transmitting at 30% DC?[/quote] I have not configured the duty cycle. in the clibrator tool there is not duty cycle setting parameter. Can you suggest me how to check the duty cycle. I hope this answer provides greater clarity. I look forward to your feedback. BR Fenil.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1651077/cc3300mod-want-to-know-the-supportMon, 01 Jun 2026 12:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c46e0a18-8d60-483d-a825-998dc4eb6623Abhijit BhagatPart Number: CC3300MOD Other Parts Discussed in Thread: CC3300 Hello, Could you please confirm whether the TI CC3300MOD supports the following features: Wi‑Fi Data Elements Power Saving Features Passpoint Wi‑Fi Direct I have reviewed the Wi‑Fi Alliance certification for the CC3300 chipset (Certificate ID: WFA128129 ); however, I could not find these features listed under the certified capabilities. Kindly clarify whether these features are supported but not covered under certification, or if they are currently not supported. Thank you for your assistance. WFA128129 (CC330X_FC20241020250131).pdfCC3300CC3300MODhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1634857/cc3350mod-cc33xx-driver-crash-during-long-running-wi-fi-scans-with-networkmanager/6365627Mon, 01 Jun 2026 11:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:021f094b-64e7-4b33-9508-ea13f97063a1Andreas DinterHi Sabeh, I just integrated this version. Unfortunately I get a lot of warnings from the Linux kernel. With the version you provided earlier this was not the case. Could this be related to the fact that we are using SDIO inband IRQ? e2e.ti.com/.../2402.dmesg.loghttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1640187/cc3551e-assist-roaming-on-wi-fi-5-rssi-triggers-fast-bssid-switches/6365422Mon, 01 Jun 2026 08:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:996cfa84-cd55-4cf4-ae9f-0561dc53e1c4Martin EgholmHi Josh, I&#39;ve been working a little bit with this since. So I have some additional comments. With respect to the second observation (long scan-time), and your suggestion about limiting the channels scanned for. I tried doing this using the &quot; WlanSet_e#WLAN_SET_LISTED_CHANNELS_FOR_SCAN &quot;, which would be more or less perfect for this (and also for limiting the implicit scanning when connecting - &quot; first observation &quot;) - at least when reading the documentation in wlan_if.h : ### Wlan_Set Type &#39;WLAN_SET_LISTED_CHANNELS_FOR_SCAN&#39; Set a list of channels for next/upcoming Scan/Connect This command sets a list of channels that will only be set when doing scan or connect, the list is used only one time, meaning you need to set it again if you cant to list specific channels for scan/connect, after you scan or connect the listed channels will be resetted and the next scan/connect will be on all possible channels However, this feature is not implemented. It simply returns WLAN_ERROR_TYPE__INVALID_PARAM_SET_TYPE (fallthrough value in wlan_if.c#Wlan_Set() (SimpleLink Wi-Fi SDK 10.10). With respect to the &quot; dead second &quot; ( third observation ), I believe it&#39;s neither of the things you suggest. * Waiting on a semaphore: I guess the FreeRTOS scheduler would have scheduled others tasks in then. That is not the case - all tasks are exhausted. * Scanning: That would have been visible from the WireShark logs (in monitor mode), and there is nothing in that second (line 288 -&gt; 289, time-stamps 485.463624909 -&gt; 486.641748602) (and the that extra scanning is seen in the log afterwards ). * Connection handling: Again, nothing in the WireShark logs to support this, and the &quot;extra scanning&quot; does not start until after this &quot;dead second&quot;. Finally, I&#39;ve noticed this only occur when calling &quot; wlan_if.c#Wlan_Connect() &quot; with a specific SSID(+BSSID); if calling with a profile-index (as done in wlan_cmd.c#cmdWlanProfileConnectCallback() - with the flag WLAN_CONNECT_FLAG_PROFILE_CONNECT ), this &quot;dead-second&quot; is not there . (Maybe of value for your backend team) Update with DHCP improvements (2026-06-02): With respect to &quot;the DHCP behavior&quot; (not needing to do full DHCP cycle when roaming) I&#39;ve modified network_lwip.c#link_callback() ever so slightly (added knowledge about roaming, and not calling dhcp_stop() / dhcp_start() on link-down/up, but just calling dhcp_renew() on link-up. When using connect-using-profile (not adding the &quot;dead second&quot;, as mentioned under the &quot;finally&quot;-section above), roaming on a 2g4 network can now be done seemingly fast. Here&#39;s a roaming example with timestamps from TeraTerm; the cycle takes ~600ms from roam-request to DHCP-renew: &gt; wlan_profile_connect -i 0 [2026-06-02 08:24:42.795] Doing command &quot;wlan_profile_connect&quot; [2026-06-02 08:24:42.801] [2026-06-02 08:24:42.858] Informing lwIP about roaming-disconnect [2026-06-02 08:24:42.867] [2026-06-02 08:24:42.867] [WLAN EVENT HANDLER] WLAN_EVENT_DISCONNECT [2026-06-02 08:24:42.878] [2026-06-02 08:24:42.878] status_callback==DOWN [2026-06-02 08:24:42.881] [2026-06-02 08:24:42.881] link_callback==DOWN - NOT stopping DHCP as per early disconnect callback [2026-06-02 08:24:42.893] link_callback==DOWN [2026-06-02 08:24:42.893] [2026-06-02 08:24:42.893] [WLAN EVENT HANDLER] Device disconnected from the AP: xyz-hotspot, [2026-06-02 08:24:42.898] BSSID: f0:5c:19:80:2b:26 on application&#39;s request [2026-06-02 08:24:42.944] [2026-06-02 08:24:43.274] [WLAN EVENT HANDLER] WLAN_EVENT_CONNECTING, STA is connecting [2026-06-02 08:24:43.284] [2026-06-02 08:24:43.284] [WLAN EVENT HANDLER] WLAN_EVENT_ASSOCIATED, STA associated [2026-06-02 08:24:43.343] [2026-06-02 08:24:43.343] lwIP early connect: Same SSID as before, registering DHCP renew [2026-06-02 08:24:43.352] [2026-06-02 08:24:43.352] [WLAN EVENT HANDLER] STA Connected to the AP: xyz-hotspot , BSSID: f0:5c:19:80:90:83 [2026-06-02 08:24:43.360] [2026-06-02 08:24:43.365] status_callback==UP, local interface IP is 10.145.154.12 [2026-06-02 08:24:43.384] [2026-06-02 08:24:43.384] link_callback==UP - renewing DHCP [2026-06-02 08:24:43.393] DHCP renew err: 0 Regardless, the observations/questions above are still valid. It would be nice to be able do specific BSSID roaming with the same speed as profile-connect, etc. BR, Martin