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/1642404/cc3135-certificate-errors-over-wi-fi-but-not-ethernet-on-cc3135-with-tls-1-2-connecting-to-aws-mqtt-broker/6343607Wed, 13 May 2026 13:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e76cf262-bc26-4d1a-b8da-7c3c4cd7f85bShlomi ItzhakHi, Just to explain on AWS in general, since it is a full IoT infrastructure and not just an open MQTT broker, it does required full authentication. This is why you needed to set your certificate and matching key. As for TLS1.3, AWS supports it of course but does not mandate it. If the mbedtls library is not compiled with TLS1.3 but declares it during TLS, AWS would start using TLS1.3 and fail. With CC3135, the internal TLS stack is not mbedtls. It is TLS1.2 only. This is why we have the external TLS1.3 example so we open a regular socket and use mbedtls on top so we get TLS1.3 to work. Now, with either mbedtls or the internal stack, the files can be flashed using the SlNetIfWifi_loadSecObj(). It can also be flashed using an external tool like Uniflash. The difference is on the actual setting of the certificates to the TLS stack. With mbedtls, you do it via the SlNetIfWifi_sockstartSec() where it calls the SetSockOpt() which eventually calls the mbedtls_xxx methods that &quot;copies&quot; the content of the files to mbedtls. With the internal stack, you just need to pass the name of the file and the NWP knows to open the file and use it. This is done in the same SlNetIfWifi_sockstartSec() but it should call sl_SetSockOpt() instead. So the sl_SetSockOpt should not be defined. Regards, Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1645476/cc2564moda-reason-for-not-recommended-for-new-designWed, 13 May 2026 12:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:21fe0a5b-3aee-45fe-9f5a-bd93696c406fMarvn ArcangelPart Number: CC2564MODA Hi Experts, It looks like this part is going obsolete soon. Can you provide a reason why? I can&#39;t find any Product Discontinuance Notification anywhere. Thanks! MarvinCC2564MODAhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1645387/cc3301mod-cc3300mod-rambtl-conf-file-download-issueWed, 13 May 2026 09:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:dcf3d1cd-52b2-4939-9d9b-ef4570deb010Ashok DhumakPart Number: CC3301MOD Other Parts Discussed in Thread: CC3300 Hi Josh, We are working on CC3300 interface with STM32. I am working with Yogesh, who is sending you queries for some time. I am writing separately since he is on leave. As we mentioned, we were able to upload bootloader binary to CC3300 with following change. We require to comment code under “if (isLastRecord &amp;&amp; (0 == os_strcmp(&quot;rambtlr&quot;,containerName)))” which disable interrupt before sending last chunk and enable interrupt after sending complete. But with above change, after binary transfer was completed, below code of “RAM BL fail” Report(&quot;\n\r-------------- Wait for RAM BTL UP&quot;); if(fwEvent_Wait(OSI_WAIT_FOR_SECOND * 2, HINT_SECOND_LOADER_INIT_COMPLETE) == -1) { Report(&quot;\n\rdidn&#39;t receive RAM HINT_SECOND_LOADER_INIT_COMPLETE&quot;); return WlanError(WLAN_ERROR_SEVERITY__HIGH, WLAN_ERROR_MODULE__DEVICE, WLAN_ERROR_TYPE__RAM_LOADER_INIT); } Our queries: Why “cmd_SetTimeoutMs(100)” set while disabling IRQ. What might be the reason bootloader binary transfer completed correctly in our case after commenting the IRQ disable enable code. How host is confirming RAM BTL Up case. Can you please provide a timeframe for same in reference trace provided by TI. Thanks,CC3300CC3300MODCC3301MODWireless Infrastructurehttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643436/cc3120-behavior-of-cc3120-2-4-ghz-when-router-uses-smart-connect-band-steering-same-ssid-for-2-4-5-ghz/6343340Wed, 13 May 2026 09:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:58808678-9681-4ff9-8440-0b5752c00ebaShlomi ItzhakHi, CC3120 does not support 11k/11v, only CC3135. The station would not advertise it so even if the AP does support it, the AP would not expect the station to respond to any agile multiband commands. What you should look for on the association request is under &quot;RM Enabled Capabilities&quot; IE. AP that support 802.11k, needs advertise it in its beacons both Neighbor Report and AP Channel Report capability enabled. The first octet of the RM Enabled Capabilities hold the Neighbor report field. The Third octet of the RM Enabled Capabilities hold the AP Channel Report capability field. When both fields are set to one, the AP support 802.11k. Regards, Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642507/cc3501e-need-clarification-over-spi-driver-example-code/6343306Wed, 13 May 2026 09:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e0c5cb5b-6f8e-4a71-8c99-70a2d6fa6e5evignesh sHi Josh, We tested using an ST device as the SPI controller and the SimpleLink device as the SPI peripheral. However, the peripheral was unable to receive the data. We verified using a logic analyzer that the SPI clock and data signals are present on the SPI bus. Regards vignesh shttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1637746/cc2564c-anomalous-le-disconnections-when-advertise-is-enabled/6343108Wed, 13 May 2026 06:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:46abe314-4bc8-4c42-b06c-1fa024be060aMir AHi, thanks for the update. I have no news from my side, I&#39;ll keep waitinghttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642130/cc3551e-uart-driver-read-issue/6342813Wed, 13 May 2026 02:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:eb446921-7831-4bcf-b2a5-e843932c5dfbBLiuHi Edward, Sorry for misunderstanding. Yes, I only added the sleep without a larger data burst. I&#39;ll give it another try once I am back from business travel. Thanks for your patience.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642971/cc3551e-nimble-passkey-pairing-issue-with-ios-and-android/6342807Wed, 13 May 2026 02:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4d06ddfe-cea0-4269-bff3-3511b49e87bfBLiuHi Vignesh. I&#39;ll look into your issue more once I am back from business travel. Thanks for your patience.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1637746/cc2564c-anomalous-le-disconnections-when-advertise-is-enabled/6342804Wed, 13 May 2026 02:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9218a332-f716-46ac-b7af-b9ec9f36d905BLiuHi Mir, I wanted to let you know that I&#39;m currently on business travel for about another week. I can continue into your issue once I am back. Thanks for your patience.https://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/6342274Tue, 12 May 2026 17:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:42674c10-c43b-4d7a-b469-e18c0d31e52fSabeeh Khan1Hi Jihu, I&#39;m attaching a zip file &#39;wowlan_offset_change_new_driver.zip&#39; with the changes that will allow offset=0 to be defined at the first byte of the IP header. Please note that this change also requires the driver to be updated, so i&#39;ve included a driver patch as well as the updated FW. Please try this patch and see if it matches your expectations. e2e.ti.com/.../wowlan_5F00_offset_5F00_change_5F00_new_5F00_driver.ziphttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1641606/cc3351-cc33xx-with-unsynchronized-service-discovery-usd-crash/6342131Tue, 12 May 2026 16:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bef6b2c4-cb1b-4a53-b023-2aacec307531Sabeeh Khan1Hello Jason, Thanks for the information. Again, NAN is not a supported feature on the cc33xx device. I believe the kernel/supplicant is sending the cc33xx a FW role that it is not able to understand and that is why you see the FW crash. We can confirm the same if you are able to collect and provide the FW logs.https://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/6342064Tue, 12 May 2026 15:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d0c02e3b-dd55-4641-8b3c-58bcd212365fSabeeh Khan1Hi Andreas, We were able to pull the bug fix for this issue into the latest release 1.0.2.14 SDK and it is now live. https://www.ti.com/tool/download/CC33XX-LINUX-MPU/1.0.2.14 Please take this release and you may use it for your internal testing and production purposes.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642404/cc3135-certificate-errors-over-wi-fi-but-not-ethernet-on-cc3135-with-tls-1-2-connecting-to-aws-mqtt-broker/6341972Tue, 12 May 2026 15:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c945e173-b18f-46ca-8353-af4ec0fe7b6dOmelio Fernando Borroto Hern&#225;ndezHi Shlomi, I have good news. We continued working on connecting to the client’s MQTT broker on AWS using the CC3220SF, based on the example code provided by TI Academy, and achieved positive results — the connection was established successfully. The step where we were stuck was the handshake, but we managed to solve it by applying the following changes: 1- Added the flag MQTTCLIENT_NETCONN_SKIP_DOMAIN_NAME_VERIFICATION to the MQTT connection parameters. 2- In the auxiliary module slnetifwifi.c, we detected a flag that was enabled and apparently forced the use of TLS version 1.3, so we disabled it. // Before: #define SUPPORT_TLS1_3 (1) // After: #define SUPPORT_TLS1_3 (0) 3- Modified the ConfigClientSocket function to force the binding of the client certificate and private key by means of: mbedtls_ssl_conf_own_cert(&amp;pTlsSock-&gt;conf, &amp;pTlsSock-&gt;srvcert, &amp;pTlsSock-&gt;pkey) // Before: if( ( ret = mbedtls_ssl_setup( &amp;pTlsSock-&gt;ssl, &amp;pTlsSock-&gt;conf ) ) != 0 ) ... // After: // Bind client certificate and private key ret = mbedtls_ssl_conf_own_cert(&amp;pTlsSock-&gt;conf, &amp;pTlsSock-&gt;srvcert, &amp;pTlsSock-&gt;pkey); if (ret != 0) { mbedtls_error(&quot;mbedtls_ssl_conf_own_cert failed: %d&quot;, ret); return SLNETSOCK_ERR_SOCKCONNECT_FAILED; } if( ( ret = mbedtls_ssl_setup( &amp;pTlsSock-&gt;ssl, &amp;pTlsSock-&gt;conf ) ) != 0 ) ... Now the device certificate and its private key are associated with the configuration before it is set with mbedtls_ssl_setup, which allows the handshake to send the client certificate and AWS IoT to accept mutual authentication. After implementing these changes, the CC3220SF was able to properly connect to the client’s broker on AWS and perform the expected interactions. We kept using mbedTLS and writing the certificates to the CC3220SF flash memory using the WriteCertFile function. I’m attaching the function definition and the successful log obtained: int32_t WriteCertFile(const char *fileName, const unsigned char *data, uint32_t len) { int32_t fileHandle; int32_t ret; uint32_t flags; SlFsFileInfo_t fileInfo; // Check if the file already exists (optional, shows notice) if (sl_FsGetInfo((const unsigned char *)fileName, 0, &amp;fileInfo) == 0) { LOG_INFO(&quot;File %s already exists. Overwriting.\n&quot;, fileName); } // Set flags: create, overwrite, no signature, failsafe, maximum size flags = SL_FS_CREATE | SL_FS_OVERWRITE | SL_FS_CREATE_NOSIGNATURE | SL_FS_CREATE_FAILSAFE; flags |= SL_FS_CREATE_MAX_SIZE(len); // Open (or create) the file. Token NULL because we are not using security fileHandle = sl_FsOpen((unsigned char *)fileName, flags, NULL); if (fileHandle &lt; 0) { LOG_ERROR(&quot;Error creating/opening %s. sl_FsOpen: %d\n&quot;, fileName, fileHandle); return -1; } // Write the full content ret = sl_FsWrite(fileHandle, 0, (unsigned char *)data, len); if (ret != (int32_t)len) { LOG_ERROR(&quot;Error writing %s. sl_FsWrite returned %d\n&quot;, fileName, ret); sl_FsClose(fileHandle, NULL, NULL, 0); // close before exiting return -1; } // Close file ret = sl_FsClose(fileHandle, NULL, NULL, 0); if (ret &lt; 0) { LOG_ERROR(&quot;Error closing %s. error %d\n&quot;, fileName, ret); return -1; } LOG_INFO(&quot;File %s written successfully.\n&quot;, fileName); return 0; } Now comes the not so good news. When we tried to replicate the changes from the CC3220SF on the CC3135 we weren’t as lucky. As I already mentioned, the CC3135 uses the internal TLS stack and from what I’ve been researching, it does not support mbedTLS (if I’m mistaken I’d appreciate it if you could correct me and explain how to properly implement it on that device). Furthermore, the only way I have found to load the certificates onto it is through the SlNetIf_loadSecObj function, and attempting to use WriteCertFile logically corrupts the NWP file system. On the other hand, since the CC3135 has a completely different logic than the academy example code structure based on mbedTLS, I can’t find in the CC3135 the &quot;equivalent&quot; elements to the changes made on the CC3220SF. That is, I can’t find any SUPPORT_TLS1_3 flag to disable for not forcing the wrong TLS version, or any ConfigClientSocket function where I could force the binding of the client certificate and private key. Basically, the slnetifwifi.c file for the CC3135, as expected, has nothing to do with the one for the CC3220SF. That’s exactly where we are stuck right now. I’m presenting all this information so that you have the complete picture and can more easily identify where the problem might be, and thus suggest possible solutions. I thank you once again for all your support. Best regards, Omelio.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1640736/cc3300mod-queries-for-uploading-cc3300mod-binaries-from-host/6341824Tue, 12 May 2026 13:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9d351073-2716-48b4-b8c5-e273bfde78caYogeshGHi Josh Prushing One good news from our side. We are able to achieve uploading of the Bootloader binary to CC3300 MOD with one observation as below. This confirmed, the binary which stored in external flash is in correct format. Our observation: While uploading binary, for last chunk of binary we came across following error and program did not come out &quot;ctrlCmdFw_ContainerDownload&quot; For testing in first attempt we commented Irq Enable (Highlighted orange) and second attempt commented Highlighted black box code. In both case program came out &quot; ctrlCmdFw_ContainerDownload&quot;. But program goes into &quot; Report(&quot;\n\rdidn&#39;t receive RAM HINT_SECOND_LOADER_INIT_COMPLETE&quot;) &quot; as mentioned below. With attempted code, program gives following error. Our queries: 1) What might be the reason for error which came across for last chunk without modifying code. Rx_status count:, headers_len, next read total length : read-unaligned size:!!! [NO_TAG] Rx length before reduction,length: !!! [NO_TAG] SPI not responsive! [NO_TAG] ASSSSEEEERRRTTT!!! 2) What is necessity of highlighted black box code. Why IRQ disable before sending last chunk and enable after. and similarly, timeout. Thanks...https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1641606/cc3351-cc33xx-with-unsynchronized-service-discovery-usd-crash/6341789Tue, 12 May 2026 13:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9606f34f-2ea6-4096-9fe7-96382c3f5024Jason HaedtThis was using supplicant 2.11https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642529/cc3351mod-calibrator-tool-command-for-fcc-issue/6341691Tue, 12 May 2026 12:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:11f5e5fb-5cb0-43cc-9f2a-670f0bab6398Parv PatelHii Josh, Thank you for the response. We cross-compile the calibrator tool again with your suggested version 1.0.0.93 For BLE PLT: [quote userid=&quot;576467&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642529/cc3351mod-calibrator-tool-command-for-fcc-issue/6335158&quot;] sh set_power_mode.sh 0 calibrator wlan0 cc33xx_plt ble_plt calibrator wlan0 plt power_mode on calibrator wlan0 cc33xx_plt tune_channel 8 0 3 calibrator wlan0 cc33xx_plt set_manual_calib -tx 1 -rx 1 calibrator wlan0 cc33xx_plt tune_channel 1 0 0 bluetoothctl power on calibrator wlan0 plt power_mode off ifconfig wlan0 down hcitool cmd 3f 11 06 hcitool cmd 08 34 1 FF 0 1 [/quote] As you suggested commands, we got below attached output in spectrum analyzer, which isn&#39;t correct: Wi-Fi Prescan: We are still facing an issue in power adjustment by set_tx command parameter tx_power . We are getting 10 dBm less power compared to the set power in command. I attached some test result: 1. setting the 20dbm power i am getting only 11.35 dbm 2. set power is 10 dbm and getting the 2.7dbm 3. set power is 0dbm and getting the -8.4dbm Kindly suggest possible solutions. Regards, Parvhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643436/cc3120-behavior-of-cc3120-2-4-ghz-when-router-uses-smart-connect-band-steering-same-ssid-for-2-4-5-ghz/6341273Tue, 12 May 2026 06:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:eb2c5f86-c7c4-475b-8736-67c90d8fe231Sandip IngleShlomi Itzhak Thank you for your response on the query that I had, I have few more follow up questions 1.Do you mean the AP advertises 11k/11v in its Probe/Assoc responses while the CC3120 does not advertise support in its Probe/Assoc requests? 2.If I want to validate 11k/v, can you confirm the exact IEs or Extended Capabilities bits I should look for in the CC3120&#39;s Probe Request and Association Request to verify it does not support 802.11k/11v? Please include the Wireshark field names if possible.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642274/cc3220sf-launchxl-cc3220-year-2038/6341262Tue, 12 May 2026 06:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3a6c806e-42ee-4852-a8a0-543ac8a4bc3bShlomi ItzhakHi, Actually no. I am always using the latest which is 3.22.x SP and SDK 7.10. Since it is SP related, and since it is only one SP behind, you should be OK. Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1644814/wl1837mod-ti-mpn-wl1837modgimoc-please-provide-the-radio-transmitting-equipment-type-approval-codeTue, 12 May 2026 06:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b957d394-29b1-4190-a421-1214767b1443Kishor YelwePart Number: WL1837MOD Hello dear, Pls provide the below details. TI MPN: WL1837MODGIMOC, please help me confirm with your company&#39;s relevant department what the &quot;Radio Transmission Equipment Type Approval Code&quot; is for this material.WL1837MODhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1644801/cc3351-ant_sel-clampingTue, 12 May 2026 05:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a0af8919-5f3a-4975-822b-2f8b6d57ca87Romain CazalisPart Number: CC3351 Hello, Is it a problem if I have a 3.3k pull-up resistor on a 3.3V power line on ANT_SEL pin? If pin is clamped then I will have a 0.5mA current in clamping diode but no damage to the chip. Do we agree? RomaingamingCC3351