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/1642274/cc3220sf-launchxl-cc3220-year-2038/6339614Mon, 11 May 2026 10:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1fd8e98a-e15b-4be9-ac56-175585b63cf6Roman JordanHi Shlomy, thanks for your answer. [quote userid=&quot;53835&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642274/cc3220sf-launchxl-cc3220-year-2038/6334882&quot;]So what I did is tested it with increasing year (set and then get) and could easily see that it the get works as expected and also that the correct date is printed on my NWP log.[/quote] You used the sp_3.21.0.1_2.7.0.0_2.2.0.7.bin of the simplelink_cc32xx_sdk_5_30_00_08 for your test, right? Regards, Romanhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642529/cc3351mod-calibrator-tool-command-for-fcc-issue/6339575Mon, 11 May 2026 09:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9a5babe9-d5da-490d-8be9-13069d5db96aParv PatelHi Josh, Do you have any updates on the remaining points (especially the WLAN TX transmission issue and BLE calibrator commands)? If you need any additional information from our side, please let me know. Regards, Parvhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1644408/cc3351-firmware-crash-using-calibrator-toolMon, 11 May 2026 09:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:00f20d47-bbb0-4fc6-963d-d19375a0dd31Ga&#233;tan FroissardPart Number: CC3351 Hello, We are using RTOS PreR9 firmware version on Zephyr. We use the calibrators commands to set the CC3351 in different TX mode. We have succeed to set TX mode and confirmed it with capture done with a hackrf board. After several minutes 2-5, we observed the CC3351 firmware crashing. Do you known if it&#39;s a known issue ? Should we use a previous released (instead of pre release) like R8.1 instead ? We configure the CC3351 in TX mode using the following commands: calibrator power_mode on calibrator tune_channel 2 0 0 calibrator set_tx -tx_power 30 calibrator start_tx Could the issue be related to the CC3351 module heat as we use the max power ? Thanks, Ga&#233;tangamingCC3351https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1638609/cc3351-ble-hci-event-data-buffer-overflow-0x1a-during-gatt-discovery/6339239Mon, 11 May 2026 05:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1f6c19d6-53e4-4248-83ac-640d7e120d06kaiwen zhangI have tried to capture cc3351 firmware log, maybe this will help to this issue. Can&#39;t upload binary file here, I will email it.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1638231/cc3351-ble-gatt-service-discovery-fails-on-ti-cc33xx-sdio-due-to-hci-acl-packet-size-exceeding-driver-limit-255/6339108Mon, 11 May 2026 02:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bc200bb0-ed5f-4692-963b-09ff79558d14kaiwen zhangHi Sabeeh, I have tried to proceed the same test with UART driver, but can&#39;t discovery any hci device. I also tried to capture cc3351 firmware log, maybe this will help to this issue. Can&#39;t upload binary file here, I will email it.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642130/cc3551e-uart-driver-read-issue/6339092Mon, 11 May 2026 01:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f28aac28-58f3-4ecd-82af-936a17934b0fEdward PeekNote that both the sleep (or high baud rate) and large data burst are needed to reproduce it. It looks like your repro attempts are doing only one or the other. Using your code (with the sleep) I can hit it by: Correcting the size of `input` so that the read does not smash the stack ( char input -&gt; char input[32] ). Pasting in 33 characters into the terminal &quot;33b33b33b33b33b33b33b33b33b33b33b&quot;. That results in &quot;P&quot; rather than the expected &quot;P1&quot; Typing in a single character after this results in &quot;2&quot; rather than the expected &quot;1&quot; This illustrates that the final byte of the pasted string gets stuck in the ring buffer until new data comes in through the HW FIFO. e2e.ti.com/.../Screencast-from-2026_2D00_05_2D00_11-13_2D00_35_2D00_15.mp4https://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/6338961Sun, 10 May 2026 05:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b582f961-2cdf-432b-9fd2-0f5aa1939522Shlomi ItzhakHi, CC3120 does not have a 5GHz radio so it will only see he 2.4GHz band. Whatever happens on the 5GHz band is completely out of band for CC3120. 11k/v which is part of the agile multiband is reported on the Probe Responses and Association Responses so with CC3120 it is not set so the AP knows that the device is not part of the game and should allow it to connect on the 2.4GHz. If you ss a specific issue let us know. Regards, Shlomihttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1640697/am625-am62xx-cc33xx-sdio-wifi-not-detected-cmd-timeout-mmc2-init-failure/6338930Sat, 09 May 2026 18:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7a462d0d-a163-4747-85bb-d16c0c7369b3Navami GSHi Sabeeh, This resolved the issue. Thank you for your continuous response.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643699/cc3551e-encountered-an-issue-while-testing-ota_example/6338698Fri, 08 May 2026 22:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e66f309d-76a4-4596-a350-9a609e75a84fABHi Zhong, Yes, this is a known issue and we are looking into it. I will get back to you once we have additional information on this behavior.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642130/cc3551e-uart-driver-read-issue/6338344Fri, 08 May 2026 16:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:27487aac-3bc6-469c-9442-8f19f682453fBLiuHi Edward, I first added the usleep after the while(bytesRead == 0) block and I wasn&#39;t stuck. Was able to get this printout. I&#39;ll be traveling next week but if there are gaps I can try the other methods you used to produce the issue.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/6338213Fri, 08 May 2026 14:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5f3b0a65-afc1-4755-9456-92e34beeb72fOmelio Fernando Borroto Hern&#225;ndezHi again, Shlomi. I think it would be useful to update you on the tests we&#39;ve been running on the CC3220SF. As I mentioned before, in this case we&#39;re trying to implement the example provided by the TI Academy with as few changes as possible, so we decided to stick with mbedtls. I&#39;m going to send you the detailed LOGs I&#39;m getting when trying to connect the CC3220SF to the client&#39;s AWS broker, so you can see the exact program flow. Note that everything goes smoothly until the handshake phase, which fails and returns error 0x7880. This code sends all certificates in .PER format (the CA, the client certificate, and the private key), since that&#39;s what worked for us on our own broker. It also uses MQTT 3.1.1 with QoS 0, TLS version 1.2, and has no WILL configured. As you can see, we&#39;ve simplified it as much as possible but haven&#39;t had any success. I&#39;ve been following recommendations from similar posts on the Forum, especially those discussed here: e2e.ti.com/.../cc3230sf-cc3230sf-mqtt-errors--688--457--456-migrating-from-hivemq-one-way-tls-to-aws-iot-core-mutual-tls-production-certificate-storage-questions which is a case very similar to ours, even in the LOG structure. Fortunately, our colleague was able to solve their problem by changing the QoS and removing the WILL, but we haven&#39;t had the same luck following those same recommendations. It&#39;s important to point out that our original device (MSP432 + CC3135), which uses Ethernet and Wi-Fi, achieved a successful connection to the client&#39;s AWS broker without any issue, over Ethernet with these same certificates — which in that case were in PEM format — and with QoS 1 and WILL configured. We tried those same parameters over Wi-Fi with the CC3220SF but also had no luck. Once again, thank you very much for your support. 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/6338002Fri, 08 May 2026 12:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0491ba55-a655-4f34-9b16-932529dea950YogeshGHi Josh, Your input related to &quot; bus_sendWriteCommand()&quot; helps us lot. We were able to achieve &quot;Get Device Info&quot; command completely. Now from next week we will start binary upload to CC3300 MOD activity. We will get back to you on same. Couple of queries for reference waveform from TI. 1) We understood below patch for &quot;set_device_fuse_mac_addr&quot;. Kindly confirm same. I sent you command over email. 2) What exactly activities handled in &quot;set_device_fuse_mac_addr&quot;. Thanks....https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1641878/cc3220sf-launchxl-cc3220-projects-with-unresolved-inclusion-of-c-standard-library-header-files-in-ccs/6337963Fri, 08 May 2026 11:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3e391fa2-1fb8-430b-b537-bb2432cc397aJuan Pablo NovoHi Josh, [quote userid=&quot;566998&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1641878/cc3220sf-launchxl-cc3220-projects-with-unresolved-inclusion-of-c-standard-library-header-files-in-ccs/6336847&quot;]The stdxxx.h files in these locations are the same, they have the exact same contents. Adding either will be sufficient.[/quote] When importing the examples with CCS 12.8.1, why CCS doesn&#39;t add ${CG_TOOL_ROOT}/include/c or ${CG_TOOL_ROOT}/lib/src to support the C Standard Library header files? It should do it, doesn&#39;t it? Is it a bug? [quote userid=&quot;566998&quot; url=&quot;~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1641878/cc3220sf-launchxl-cc3220-projects-with-unresolved-inclusion-of-c-standard-library-header-files-in-ccs/6336847&quot;]I took a look at stdio.h and it seems like the declaration is just in this file, but the actual definition should be in the C source code, so I don&#39;t think this will be able to have the same hover functionality. Can you confirm that your hover definition works for other functions defined outside of the source code in CCS 12.8?[/quote] For example, when I hover over a GPIO_write call (it is bolded in the editor): I can see the function declaration defined in GPIO.h: What I can neither understand is this: If I remove the #include in my program, I still see GPIO_write() (and GPIO_init(), etc) bolded and with the hover functionality working. Even if I begin writing gpio in the editor, it shows me all the related options: These are the included files in my program: I have checked that none of them have a reference to GPIO.h It is the same for SPI.h and SPI related functions. When I remove driver headers in CCS 9.3.0 with CC1310 projects, all coded calls are not recognized as expected. And the same for the C Standard Library header files. I don&#39;t understand what is happening with CCS 12.8.1 with CC3220 projects. Could be related to using CLang compiler? I have tried to change the compiler, but I didn&#39;t finished because I don&#39;t want to break anything: Thanks!https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643864/cc3351-firmware-doesn-t-reboot-after-crashFri, 08 May 2026 09:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2d58fd76-a129-4fd2-b2e0-84d8fba158deGa&#233;tan FroissardPart Number: CC3351 Hello, I use Zephyr RTOS with STM32 and CC3351 wired with a SPI connection. This issue appear either on R7.2 or R8.1. Some times, I have a crash on the CC3351 (for example I had one with the calibrator tool). I see in the CC3351 logs an explicit log saying the firmware has crashed as follow: 1,,2026-05-07 18:45:08.090,0,0,main.c:378,1,main_dump(),Flushing PHY M0 log buffer,800013de2000 1,,2026-05-07 18:45:08.090,0,0,main.c:382,1,main_dump(),&quot;Finally, I can die peacefully....&quot;,80001bde2000 But, afterall the CC3351 doesn&#39;t reboot. In my event handler it seems I don&#39;t receive any event of type WLAN_EVENT_FW_CRASH. In my configuration file I have let: core.no_recovery = 0x00 So, I would expect the CC3351 to reboot in case of crash. Could you tell me if there is another configuration to enable in order to make the CC3351 reboot in crash of crash ? When the event crash should be sent ? After of before the chip reboot ? In case the device reboot after a crash, should I stream again the firmware to the chip ? I&#39;ve attached to this ticket my configuration file. Thanks, Ga&#233;tan cc33xx-conf.txtgamingCC3351https://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/6337866Fri, 08 May 2026 09:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c335bc00-5854-444d-848f-28c1792a9c81Zhang XianglongHi Sabeeh, Please find the latest logs from the following link: drive.google.com/.../15n_1fFZ4jFi7GhYuNZ1xisk4BIKKAtF8https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1638585/cc3351-sdio-error-and-dump-occured-sometimes-when-wakeup/6337390Fri, 08 May 2026 03:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d17ee721-fd62-4112-9432-0bf7a9e54c00Xing SUHI Sabeeh Khan1 , No, this isn&#39;t a common use case, but we do encounter it here. We&#39;ve now found a workaround to avoid this situation, so I think this ticket can be closed. Thank you very much.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1633470/cc3551e-cc3551e-mqtt-tls-connection-to-test-mosquitto-org-8884-using-client-certificates/6337372Fri, 08 May 2026 03:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f43f9fbe-fdb9-4c41-99b6-283126fe484fBLiuHi Vignesh, we now have released an Azure demo example which you can look at. The device talks to Azure via MQTT after a successful mbedTLS handshake: https://github.com/TexasInstruments-Sandbox/simplelink-wifi-demos It uses SNTP to set time by capturing them from the servers (you do that in your code as well but without the datetime_init that is done in the Azure example). The error you are getting with MBEDTLS_SSL_SERVER_CERTIFICATE is related to how the device cannot verify the server certificates, and time / expiration can definitely play a role. Another thing I find interesting is you are parsing mosquitto_org_der even though your comment says (PEM). Additionally, in this section: struct addrinfo *res = NULL; char port_str[8]; snprintf(port_str, sizeof(port_str), &quot;%d&quot;, broker_port); ret = DNS_IF_gethostbyname(broker_host, &amp;serverIp); if (ret != 0) { UART_PRINT(&quot;[HTTPS] DNS resolution failed: %d\n\r&quot;, ret); ret = -3; } // if (lwip_getaddrinfo(broker_host, port_str, &amp;hints, &amp;res) != 0 || // res == NULL) { // UART_PRINT(&quot;\n[TLS] DNS failed for %s\n\r&quot;, broker_host); // return -1; // } sock_fd = lwip_socket(res-&gt;ai_family, SOCK_STREAM, 0); if (sock_fd &lt; 0) { UART_PRINT(&quot;\n[TLS] socket() failed\n\r&quot;); lwip_freeaddrinfo(res); return -1; } I don&#39;t think this is the root cause of your issue but res is still null and you are trying to dereference it.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643332/cc2642r-pcn-report/6337341Fri, 08 May 2026 02:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2bf8cb34-3ac2-4afb-8c93-997c76adef05Tommy TzengHi Rafael, got it, thanks.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1642130/cc3551e-uart-driver-read-issue/6337330Fri, 08 May 2026 02:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:74fd851e-3ff2-4955-ad98-6499252cfcbfBLiuOk I&#39;ll take a look tomorrow.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643699/cc3551e-encountered-an-issue-while-testing-ota_exampleFri, 08 May 2026 02:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:675c9e16-eb4e-471d-b3fe-10388bc76d78zhong weiPart Number: CC3551E I used ota_example to generate three different versions of firmware for testing the OTA functionality of Vendor_Image. The version numbers are 0.0.0.1, 0.0.1.0, and 0.0.1.1. First, the 0.0.0.1 version of the firmware runs on Vendor_Image_Slot_1. Then, I successfully ran an OTA update to upgrade the firmware to 0.0.1.0, and after the OTA, the 0.0.1.0 version of the firmware runs on Vendor_Image_Slot_2. Then , I attempted to perform another OTA update from the 0.0.1.0 (Vendor_Image_Slot_2) version to upgrade the firmware to version 0.0.1.1. I completed the firmware download and installation, but after requesting a reboot, I saw the following log s : [OTA] WARNING: STAGED updates found after unexpected reboot. [OTA] These updates cannot be applied and will be removed. [OTA] Rejecting and cleaning up, please wait... [OTA] Done. Please re-download and install the updates. I have tried multiple times and the result is always the same: OTA from Vendor_Image_Slot_1 to Vendor_Image_Slot_2 is successful, but OTA from Vendor_Image_Slot_2 to Vendor_Image_Slot_1 fails. Could you please help analyze what might be causing this issue? ota_log.txtCC3551E