Wi-Fi forum - Recent Threads

CC3350: CC3350: CMD_DOWNLOAD_INI_PARAMS never completes (no IRQ, no completion hint) despite firmware download succeeding reliably

Sebastian Ong — Thu, 13 Aug 2026 06:53:51 GMT

Part Number: CC3350
Other Parts Discussed in Thread: BP-CC3351, LP-AM243, CC3351

Setup: Custom board, STM32WBA65 host MCU, CC3350 (WiFi-only, confirmed via physical package marking — no BLE). Host talks to the CC3350 over SPI/WSPI.

SDK/package versions used:

Currently running firmware from CC33XX RTOS MCU package R8.1
Also fully tested against R5 (older firmware/conf triad) — same failure, not SDK-version-specific
Cross-referenced the CC33xx Linux driver package v1.0.2.17 for protocol details not in the RTOS SDK
Reference comparison platform: BP-CC3351 + LP-AM243 (CC3351, not CC3350 — flagged below)

Bring-up sequence and where it stops:

Boot ROM alive — passes reliably
HINT_ROM_LOADER_INIT_COMPLETE confirmed — passes reliably
2nd-stage RAM bootloader download (chunked) — passes reliably
Main firmware download (chunked, ~725 chunks) — passes reliably
CMD_DOWNLOAD_INI_PARAMS — never completes. No error, no timeout signature — completion hint bit never sets, IRQ line never asserts again.

Ruled out: wire content (byte-identical to working reference, confirmed via logic analyzer), IRQ line electrically dead after this command specifically (6 pulses on reference vs. zero on ours, same physical pin that works fine elsewhere), timing/settle delays, SPI clock speed (swept 500kHz-12.5MHz, fails identically throughout), conf file content (fixed a real 1-byte truncation bug, tested enable_ble both ways, zeroed every BLE field — no effect), checksum validity, host-side struct layout, chip identity.

Questions: CC3350-vs-CC3351 handling differences for this command, meaning of undocumented rx_status upper bits (seeing 0x03000000), and what FW-side precondition could gate only this command's completion while stages 3-4 work fine.

CC3120: Need Information About Disconnect reason.

Sandip Ingle — Wed, 12 Aug 2026 07:01:14 GMT

Part Number: CC3120

Hi ,

In My Smart Lock i am using cc3120 as Netowrk porcessor and

this is battery powered device, one of our lock field user has expericened Battery drain from 76% to 0 % withing two weeks which is very unusual ,I am doing an investigation for that I dont see any significant disconnects and not even AP Disconnects but AP disconnect reason code is not consistenace , we are using below API for AP Disconnect is it possible to get possible reasoncode values using for the function INLINE void wifiPlatformAppCallbackWlanEvent(wifiPlatformWlanEvent_t wlanEvent,

uint32_t ReasonCode)

CC3220SF: HTTPClient_sendRequest() hangs forever when internet is missing

Maxime Vinzio — Tue, 11 Aug 2026 10:12:12 GMT

Part Number: CC3220SF

We have a connection manager thread that will check the connection to our servers. Depending if wifi is connected and if IP address is aquired we check DNS can solve our domain name, then produce a HTTP GET request to recover the status of our server.

We ran into an issue when after a power outage the whole network around the device restarts and end up unusable until we restart the network processor.

The user's network look like this:

WAN <----| Router 1 LAN | <------LAN---->|WAN router 2 + DHCP | <-- Wi-Fi network -> CC3220SF

If you see the following logs the issue is when sending the GET request. Other steps do not have any error.

connection-manager.c: connMan: wifi=0 ip_acquired=0
connection-manager.c: connMan: inet=0 (was 0)
connection-manager.c: connMan: wifi=0 ip_acquired=0
connection-manager.c: connMan: inet=0 (was 0)
connection-manager.c: connMan: wifi=0 ip_acquired=0
connection-manager.c: connMan: inet=0 (was 0)
connection-manager.c: connMan: wifi=0 ip_acquired=0
connection-manager.c: connMan: inet=0 (was 0)
connection-manager.c: connMan: wifi=0 ip_acquired=0
connection-manager.c: connMan: inet=0 (was 0)
connection-manager.c: connMan: wifi=0 ip_acquired=0
connection-manager.c: connMan: inet=0 (was 0)
network-manager.c: Wi-Fi event received: 2
network-manager.c: Processing signal: eStateMachineEventConnectedToAp
network-manager.c: Wi-Fi event received: 0
connection-manager.c: connMan: wifi=1 ip_acquired=1
connection-manager.c: connMan: checking DNS resolution
connection-manager.c: connMan: create handle
connection-manager.c: Set headers
connection-manager.c: Connect client
connection-manager.c: Send request
WD LR:0x1016b9d

The corresponding SL calls are


connection-manager.c: connMan: checking DNS resolution ->
    dns_getHostByName() -> platform_dns_getHostByName() -> SlNetIfWifi_getHostByName() -> sl_NetAppDnsGetHostByName()

connection-manager.c: connMan: create handle ->
    httpClient_create() -> platform_httpClient_create() [networkProcessor_acquireNwpResources()] -> HTTPClient_create()
    (no sl_* calls — just control-block/buffer malloc)

connection-manager.c: Set headers ->
    httpClient_setHeader() -> platform_httpClient_setHeader() -> HTTPClient_setHeader()
    httpClient_setHeaderByName() -> platform_httpClient_setHeaderByName() -> HTTPClient_setHeaderByName()
    (no sl_* calls — local header-list bookkeeping only)

connection-manager.c: Connect client ->
    httpClient_connect() -> platform_httpClient_connect() -> HTTPClient_connect() -> HTTPClient_connect2() -> SlNetSock_connectURI():
      - SlNetUtil_getHostByName() -> ... -> sl_NetAppDnsGetHostByName()   (re-resolves host)
      - SlNetSock_create() -> SlNetIfWifi_socket() -> sl_Socket()
      - setSocketOpts() ->
      - socketConnectTimeout() -> SlNetSock_connect() -> SlNetIfWifi_socketConnect() -> sl_Connect()
            (retried on SLNETERR_BSD_EALREADY)

connection-manager.c: Send request ->
    httpClient_sendRequest() -> platform_httpClient_sendRequest() -> HTTPClient_sendRequest() -> sendRequest():
      - sprsend() -> SlNetSock_send() -> SlNetIfWifi_send() -> sl_Send()          (request line/headers)
      - socketRecvTimeout() -> SlNetSock_recv() -> SlNetIfWifi_recv() -> sl_Recv()   (response read)

Here is the corresponding NWP log

nwp_outage_hang.log

We tried setting socket recv timeout and send timeout with no succes.

CC3351: RAM Bootloader crash on cc33xx_fw.bin download start

Liudmyla — Tue, 11 Aug 2026 07:26:50 GMT

Part Number: CC3351

Hi Team,

I'm porting the CC33XX RTOS MCU SDK R9 for the STM32 host with the CC3351.
The host communicates with the companion IC over SDIO. I implemented the SDIO driver and ported the osi_filesystem and osi_freertos modules.

On Wlan_Start the host powers on the IC, waits for the ROM-loader init-complete boot IRQ, reads device info, then downloads the containers chunk-by-chunk, waiting for a boot IRQ after each stage.

What works:
Power-on, the device-info read, and the 2nd-loader download all succeed. The chip boots into the RAM Bootloader and the host receives the init-complete signal (HINT_SECOND_LOADER_INIT_COMPLETE).

What fails:
On the very first cc33xx_fw.bin chunk received, the IC FW asserts and never recovers ("Finally, I can die peacefully...." log ). The error is returned to the host ("FwEvent_CallHandlers: GENERAL ERROR event received! FW is stuck"), and the start procedure stops. From the Logger capture:

7517 20.564 Dispatcher incomming command CMD_CONTAINER_DOWNLOADS: 0x80 0xb007c0de 0x10002
7518 20.564 osprey dispatcher: Event received mask 0x1
7519 20.564 ERROR, CMD sent while FW wakeup(waiting for INI DOWNLOAD), cmd sent: (36)
7520 20.564 ASSERT ERROR at address 21cdda
7521 20.565 ASSERT ERROR 0
7522 20.565 Flushing PHY M0 log buffer
7523 20.565 ############## Main Dump ##############

I've attached the Wireshark/Logger capture of the full start procedure up to the crash: cc33xx_rambtlr_crash.zip

The firmware reports it is in FW-wakeup, "waiting for INI DOWNLOAD," at the exact point I send the first cc33xx_fw.bin FW-container chunk (CMD_CONTAINER_DOWNLOADS, cmd 36). That is confusing, because in the flow above the FW container is downloaded before the INI params. Could you clarify, for R9 specifically:

1) What is the exact expected host<->device handshake between the 2nd-loader (RAM Bootloader) boot and the cc33xx_fw.bin download? Is there any additional timeout for the host to wait for after the 2nd loader boot before it may issue the first FW-container chunk?

2) What does the "waiting for INI DOWNLOAD" state expect the host to send next - the INI/conf container or the FW container? Is the INI download expected before cc33xx_fw.bin in R9?

Thank you in advance!

CC3220SF: CC3220SF: SlNetSock_setOpt with SLNETSOCK_OPSOCK_SND_TIMEO returns 0xffffffea (-22)

Maxime Vinzio — Mon, 10 Aug 2026 14:36:28 GMT

Part Number: CC3220SF

I am using CC3220SF with SimpleLink networking and I am setting socket options through SlNetSock_setOpt in the HTTP client path.

Calling SlNetSock_setOpt for SLNETSOCK_OPSOCK_SND_TIMEO fails with return value 0xffffffea.

Here is my code

/* Set socket send and receive timeouts to prevent indefinite hangs */
    SlNetSock_Timeval_t sockTimeout;
    sockTimeout.tv_sec = 30;   /* 30 seconds timeout */
    sockTimeout.tv_usec = 0;

    /* Set send timeout */
    retVal = SlNetSock_setOpt(
        sd,
        SLNETSOCK_LVL_SOCKET,
        SLNETSOCK_OPSOCK_SND_TIMEO,
        (uint8_t *)&sockTimeout,
        sizeof(sockTimeout));

    if (SLNETERR_RET_CODE_OK != retVal)
    {
        return retVal;
    }

Is this supported?

Maxime

CC3351: How to port on freertos on ITE soc.

Island Wei — Mon, 10 Aug 2026 06:14:34 GMT

Part Number: CC3351

The SoC is ITE9836.

WL1831MOD: Control / behaviour of WL_IRQ during boot and timing of initialisation

Yani Dubin — Mon, 10 Aug 2026 02:26:19 GMT

Part Number: WL1831MOD

Hi,

We have a custom board using the WL1831mod where there is an external 10k pullup on the WL_IRQ line. We have recently discovered some issues when stopping/restarting the WLAN stack while BT remains active, and have traced it to our control of this line during the reset.

While we've made some tweaks which seem to resolve the issue, we'd like to check with you for best practices around timing here.

We were driving WL_IRQ low, then releasing it 2ms after driving WL_ENABLE. We then immediately registered it as an input IRQ.

Can you please comment on:

1) how long WL_IRQ must remain low after assertion of WL_EN to ensure we safely enter operational rather than debug mode?

3) how long until the module FW takes control of WL_IRQ and actively drives it low (so we can be sure there will be no IRQ triggered by the pullup pulling the line high, or any transients during module initialisation)

4) how long until we must stop driving WL_IRQ low (to avoid any issues with e.g. FW SDIO bootloader)

My hope is that we can use the answer from (1) to ensure we avoid entry to debug mode, and (2) to ensure we don't register for interrupts too soon. If (3) applies, and is less than (2), then we can set it as an input but delay flushing and registering for interrupts.

The design is not a new one, so removing the external pullup isn't an option. We're using a microcontroller, this is not Linux based.

Regards,

Yani.

CC3351MOD: Support Required for BLE TX Power Issue with Default CC3351MOD FCC BIN

Fenil Ladani — Fri, 07 Aug 2026 12:07:40 GMT

Part Number: CC3351MOD

Hi,

During FCC pre-compliance testing with CC3351MOD used in our design for BLE, we are observing an unexpected TX power drop for the 125 kbps, 500 kbps, and 1 Mbps PHY modes while using the default CC3351MOD cc33xx-conf-fcc.bin file.

For these PHY modes, the TX power is configured to 7 dBm in the FCC BIN. However, when we apply the commands (as below) and measure the conducted output power, we observe the TX power to be close to 0 dBm. In contrast, for the 2 Mbps PHY mode, the measured TX power matches the configured value, and no issue is observed.

Additionally, for the 125 kbps, 500 kbps, and 1 Mbps PHY modes, the measured TX power appears to be inconsistent. Sometimes we measure 5-7 dBm and some time TX power is approximately 0 dBm.

To isolate the issue, we repeated the same test using the cc33xx-conf-unlimited.bin file. With the unlimited BIN, the measured TX power is as expected. The TX power drop is observed only with the default cc33xx-conf-fcc.bin.

The commands we are using are shown below.

Initial setup:

cd /usr/share/cc33xx
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

To change the channel, PHY mode, and TX power:

hcitool cmd 08 1F
hcitool cmd 3f 11 <tx power>
hcitool cmd 08 34 0 FF 0 03
hcitool cmd 08 34 <channel> FF 0 <PHY rate>

Could you please review this issue and confirm whether we are using the correct commands and test procedure? If there are any additional configuration steps or recommended commands required when using the FCC BIN, please let us know.

Attached the test results with fcc bin and unlimited bin.

125kbps_CH39_7dbm - fcc bin.pdf

125kbps_CH39_20dbm-unlimited bin.pdf

We would appreciate your guidance in resolving this issue.

Best regards,
Fenil

CC3351MOD: Verification of DUT FCC bin File for Final Device Certification

Fenil Ladani — Fri, 07 Aug 2026 11:12:07 GMT

Part Number: CC3351MOD

Hi,

We have completed the FCC pre-compliance testing (conducted band-edge and radiated spurious emission) for the CC3351MOD used in our design using the default cc33xx-conf-fcc.bin file.

During testing, we observed failures in the following areas:

2.4 GHz: Radiated spurious emission
5 GHz: Conducted band-edge

Based on the pre-compliance results, we reduced the transmit power for the affected channels and modes until the DUT met the FCC limits.

For your reference, we have attached an Excel sheet containing:

The default TX power configured in the FCC BIN. (column : fcc bin Power (dBm))
The TX power at which our DUT passed the pre-compliance tests. (column : Passed Power (dBm) during precompliance)
The channels and modes where the TX power was reduced are highlighted in yellow.

Based on these results, we have updated the default cc33xx-conf-fcc.bin file with the reduced TX power values and generated a modified FCC BIN:

Modified FCC BIN: cc33xx-conf-fcc-dut.bin

Could you please review and verify the cc33xx-conf-fcc-dut.bin file? We would appreciate your confirmation that this BIN file is suitable for use during the final FCC certification of our device.

Attached modified fcc bin file and excel sheet : cc33xx-conf-fcc-dut.zip

If you have any recommendations or require additional information, please let us know.

Regards,

Fenil

CC3220SF: Y2K36 and Y2K38 considerations for NWP

Roman Jordan — Thu, 06 Aug 2026 09:33:01 GMT

Part Number: CC3220SF

Hello,

I am using the CC3225 together with SimpleLink SDK version 5.30.00.08 and the corresponding service pack sp_3.21.0.1_2.7.0.0_2.2.0.7.bin.

I would like to know whether there are any aspects that need to be considered regarding the Network Processor (NWP) in connection with the Year 2036 (Y2K36) and Year 2038 (Y2K38) issues.

In particular:

I am not use any time functionality of the NWP neither setting the NWP time. Are there any known limitations related to the NTP implementation releated to these timestamps?

Are there any firmware or SDK updates needed, planned or recommended to ensure correct operation beyond these dates?

Best regards and many thanks, Roman

CC3351MOD: RF Switch Selection and Firmware support for Antenna Diversity

Fazle Nabi — Wed, 05 Aug 2026 06:59:57 GMT

Part Number: CC3351MOD

Dear TI Team,

We are planning to use the CC3351MODENIAMOZR Wi-Fi module in our project. Our application requires two antennas: one primary antenna and one diversity antenna.

The CC3351MODENIAMOZR datasheet recommends the RTC7608U RF switch for antenna diversity. However, we understand that the RTC7608U is approaching End of Life (EOL). Therefore, we are considering using the NJG1806K75 RF switch instead.

Could you please confirm whether the NJG1806K75 is fully compatible with the CC3351MODENIAMOZR Wi-Fi module for antenna diversity applications?

Additionally, we have one more question regarding antenna diversity. Does the CC3351MODENIAMOZR support antenna diversity through firmware or software control, allowing us to implement antenna diversity without using an external RF switch?

We appreciate your guidance and look forward to your response.

Thank you.

CC3301MOD: AM62x: Handle CC3301 nReset

Gireesh Hiremath — Tue, 04 Aug 2026 13:01:18 GMT

Part Number: CC3301MOD
Other Parts Discussed in Thread: CC3301

Hi,

We are trying to bring up the CC3301MODENIAMOZR module with a custom AM6234 board. There is a pull-up resistor on the nReset pin of the CC33xx, and presently, the slow_clk_in is not mounted, while all power pins are enabled by default at boot time. I seen Host_IRQ_WL line is high with in 2 second of power.

Earlier, without explicitly asserting the nReset pin, we were able to load the firmware and use Wi-Fi. Now, we are trying to handle the nReset pin going low for around 20 ms, but we have started getting errors like :

cc33xx_sdio mmc2:0001:2: Using SDIO in-band IRQ
cc33xx_driver cc33xx.4.auto: firmware: direct-loading firmware ti-connectivity/cc33xx-nvs.bin
cc33xx_driver cc33xx.4.auto: firmware: direct-loading firmware ti-connectivity/cc33xx-conf.bin
cc33xx: asserting nRESET for 20 ms
cc33xx: deasserted nRESET
cc33xx_driver cc33xx.4.auto: firmware: direct-loading firmware ti-connectivity/cc33xx_2nd_loader.bin
cc33xx: ERROR boot IRQ timeout
cc33xx: ERROR ti-connectivity/cc33xx_2nd_loader.bin boot signal timeout
cc33xx: ERROR FW download failed

first tried to add reset logic at different function like "cc33xx_sdio_power_on",

then added at cc33xx_probe beore nvs firmware load, still getting same error

cc33xx_sdio mmc2:0001:2: Using SDIO in-band IRQ
cc33xx: asserting nRESET for 20 ms
cc33xx: deasserted nRESET
cc33xx_driver cc33xx.4.auto: firmware: direct-loading firmware ti-connectivity/cc33xx-nvs.bin
cc33xx_driver cc33xx.4.auto: firmware: direct-loading firmware ti-connectivity/cc33xx-conf.bin
cc33xx_driver cc33xx.4.auto: firmware: direct-loading firmware ti-connectivity/cc33xx_2nd_loader.bin
cc33xx: ERROR boot IRQ timeout
cc33xx: ERROR ti-connectivity/cc33xx_2nd_loader.bin boot signal timeout
cc33xx: ERROR FW download failed

dts for reference

&sdhci2 {
status = "okay";
vmmc-supply = <&vcc_3v3_sys>;
pinctrl-names = "default";
pinctrl-0 = <&main_mmc2_pins_default>;
bus-width = <4>;
non-removable;
ti,fails-without-test-cd;
cap-power-off-card;
keep-power-in-suspend;
ti,driver-strength-ohm = <50>;
assigned-clocks = <&k3_clks 157 158>;
assigned-clock-parents = <&k3_clks 157 160>;

#address-cells = <1>;
#size-cells = <0>;
wifi@2 {
compatible = "ti,cc3301";
reset-gpios = <&main_gpio0 38 GPIO_ACTIVE_LOW>;
reg = <2>;
};

btti@1 {
compatible = "ti,cc33xxbt";
reg = <1>;
};
};

Please give suggestion.

Regards,

Gireesh Hiremath

CC3301: CC3301 band edge emissions

Juha Hämäläinen — Tue, 04 Aug 2026 06:57:10 GMT

Part Number: CC3301

We are FCC testing a gateway device with CC3301 radio, TDK DEA162450BT-1295A1 filter, and a custom PCB trace antenna, STM32U5 microcontroller running FreeRTOS and your SDK version 7. The cc33xx_fw.bin is all defaults. Now the testing lab said, that the band edge emissions at 2483.5-2500 MHz are excessive when the radio is transmitting on channel 11 at 20 dBm. We are forced to lower the TX power by 5 dB, maybe even more to have some margin.

A poor PCB design could cause harmonics, but the band edge issues are typically more up to the radio IC itself. I viewed your test report FR482308B_R02 on CC3301MOD and found that there are several band edge test results with less than 1 dB margin!

Is this really the case that your radio has that wide emissions? Is there anything we can do, except to lower the TX power? We wouldn't have chosen this radio if we knew this.

CC3351MOD: ACS not working on CC3351MOD

David Soberanis — Tue, 04 Aug 2026 01:36:00 GMT

Part Number: CC3351MOD
Other Parts Discussed in Thread: CC3351

Hello All,

We are attempting to use Automatic Channel Selection (ACS) on CC3351MOD in order to better stream video in congested environments.

However, when setting channel=0 in hostapd.conf on the latest cc33xx firmware (1.0.2.17 release), we get the following error

[24515.829125] startwlan.sh[513111]: Starting WLAN AP Setup
[24520.938564] startwlan.sh[513242]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
[24520.939350] startwlan.sh[513242]: ACS: Automatic channel selection started, this may take a bit
[24520.957440] startwlan.sh[513242]: wlan0: interface state COUNTRY_UPDATE->ACS
[24520.958051] startwlan.sh[513242]: wlan0: ACS-STARTED
[24522.958642] startwlan.sh[513111]: Successfully started WLAN AP (ssid=Robolink-controller-78cd5519b7f)
root@cdep-ccb:~# [24526.621778] startwlan.sh[513242]: ACS: Unable to collect survey data
[24526.622296] startwlan.sh[513242]: ACS: All study options have failed
[24526.622595] startwlan.sh[513242]: Interface initialization failed
[24526.622836] startwlan.sh[513242]: wlan0: interface state ACS->DISABLED
[24526.623079] startwlan.sh[513242]: wlan0: AP-DISABLED
[24526.623264] startwlan.sh[513242]: ACS: Possibly channel configuration is invalid, please report this.
[24526.623449] startwlan.sh[513242]: ACS: Failed to start
[24526.623621] startwlan.sh[513242]: wlan0: AP-DISABLED
[24526.623879] startwlan.sh[513242]: hostapd_free_hapd_data: Interface wlan0 wasn't started
[24526.624263] startwlan.sh[513242]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
[24526.657063] startwlan.sh[513242]: wlan0: interface state DISABLED->DISABLED
[24526.657639] startwlan.sh[513242]: wlan0: interface state DISABLED->DISABLED
[24526.658129] startwlan.sh[513242]: wlan0: AP-DISABLED
[24526.658532] startwlan.sh[513242]: wlan0: CTRL-EVENT-TERMINATING
[24526.659012] startwlan.sh[513242]: hostapd_free_hapd_data: Interface wlan0 wasn't started

Also, changing channels without restarting hostapd does not seem to work.

#  hostapd_cli -i wlan0 chan_switch 5 5200
FAIL
[   76.797361] startwlan.sh[2527]: wlan0: IEEE 802.11 CHAN_SWITCH HE config 0x2 VHT config 0x2
[   76.798034] startwlan.sh[2527]: CSA is not supported

We are wondering if changing channels without restarting hostapd will be supported in the future?

We ask because we are planning on launching several thousand products later this year that directly rely on CC3351MOD for network communication and video streaming

If we are unable to use ACS, it will be difficult to get consistent results in thousands of different environments. If ACS is not possible near term, then switching channels without restarting hostapd is essential since that would at least allow us to make a custom ACS solution, find a suitable channel for the environment, then change to that channel without losing a data link.

If there is any way for us to help with these features (including testing) please let us know. We are happy to help.

CC3501E: OTP Layout, Keying

ray Savarda — Mon, 03 Aug 2026 21:16:15 GMT

Part Number: CC3501E

It would probably help my earlier question about keying for the XIP hardware and encryptin XIP images if I could see the actual full OTP description, not just the high-level summary in the TRM. Is that available - maybe under NDA?
Also trying to figure out if the HUK managed by the HSM is self-created from the on-chip TRNG at some point in provisioning, or if that is something a vendor has to create manually and inject into the part as part of manufacturing config? That also then help me understand how the secure image that needs to get into the XIP flash itself ever gets encrypted to the right encryption key.

CC3501E: Secure Boot Details

ray Savarda — Mon, 03 Aug 2026 20:19:56 GMT

Part Number: CC3501E

I am trying to understand the secure boot process in deatil for a project, and have the following questions / would like confirmation I'm reading the TRM correctly. And the online Secure Boot section of the simplelink wifi page says it's "under development" (version 10.10.xx.xx).
- There is no provision to encrypt signed images to download - as there is no OTP encryption Key capability for a vendor-specific decryption key at boot time.
- There is only a privision for a single vendor ROT hash. Some other processos have multiples, with a way to securely advance to a new one. This part seems to just have one, correct?
- Assuming TI does not distribute the global private TI BL1/BL2 code signing key with it's software, during the Activation Flow (10.4.2), the BL2 bootloader must be pre-compiled and signed, and the Vendor Activation Credentials and Vendor ROT must not be signed by the TI code signing key; Is then BL2 always TI-BL1 ROT signed, and therefore not re-compileable by vendors, or once the vendor pub key hash is burned into the device OTP, can the device Auth both BL2 and Vendor code images to the new Vendor Public key?
- It looks like the Debug Interface is always required to load secure code into the device (10.4.3, Initial programming Flow, 10.4.4 Reprogramming Flow) , so vednros must populate a JTAG header on production devices?
- So the production throughput may be limited to the time it takes to load the device firmware over the 2-wire JTAG interface?
- is this constraint to program the secure code to XIP memory tied into the on-board OTFDE? I thought the HW only handled decryption, which means something else external has to encrypt the image, AND know the encryption key...I also did not see much description of how the XIP decryption key is set, other than there are 4 regions, each can have its own key. I assume these keys are manually set in the device (though not in OTP, per chapter 12?) Is there additional description of XIP encryption in another spec?

Thats probably a good start. Thanks!

CC3351MOD: LP-XDS110ET with BP-CC3351MOD stuck in "Get Device Type"

Josef G. — Mon, 03 Aug 2026 14:33:49 GMT

Part Number: CC3351MOD
Other Parts Discussed in Thread: LP-XDS110ET, , CCSTUDIO

We are using BP-CC3351MOD connected to LP-XDS110ET which is connected to a PC via USB-C. Additional power provided via Micro-USB-Connector.

Using Chrome on Windows. Installed the XDS110 drivers from CCStudio V21.

We can select the XDS110 Serial Number every time, also xdsdfu.exe -e shows 1 device.

When selecting the "Radio Tool" we get stuck in "Get Device Type":

Note: In only one of many atempts the communication worked an we were able to issue the "TX start" command with positive results on the RF side. We have not been able to get past "Get Device Type" again.

CC3301: Questions regarding CC33XX-LINUX-MPU 1.0.2.17 release

Stefan Wahren — Mon, 03 Aug 2026 09:18:21 GMT

Part Number: CC3301

Hi,

we recently tested the latest CC33XX-LINUX-MPU 1.0.2.17 release and we have questions.

[Observations]

Mixing an older Wireless driver version with the latest FW 1.7.14.389 leads to the following issue:

2026-07-31T10:06:33.314209+0200 chargesom kernel: cc33xx: ERROR ti-connectivity/cc33xx-conf.bin configuration binary size is wrong, expected 1282 got 1283
2026-07-31T10:06:33.314639+0200 chargesom kernel: cc33xx: WARNING falling back to default config
2026-07-31T10:06:35.053902+0200 chargesom kernel: cc33xx: ERROR FW is stuck, triggering recovery
2026-07-31T10:06:35.054326+0200 chargesom kernel: cc33xx: ERROR Fatal error during driver init, cannot recover
2026-07-31T10:06:37.073183+0200 chargesom kernel: cc33xx: WARNING download INI params to FW command sending failed: -5
2026-07-31T10:06:37.085185+0200 chargesom kernel: cc33xx: ERROR FW download failed

[Questions]

When do you plan to release the new firmware on https://git.ti.com/cgit/cc33xx-wlan/cc33xx-fw/ ?
Is this intended that cc33xx kernel driver version must match cc33xx firmware version?
Are there any plans to avoid this dependency in the future (e.g. for Linux mainline)?

CC3235MODASF: PLS value or target power

sumin kim — Mon, 03 Aug 2026 04:49:34 GMT

Part Number: CC3235MODASF

Hi team,

I am from Fresenius Kabi Korea, and have a question to proceed with a KC certification of the TI wifi module.

For RF testing, do you have a channel-by-channel output power table for the Wi‑Fi module?

Thank you in advance for your support.

CC3551E: 2.4G+5G Dual Frequency PCB Onboard Antenna Design

Lumina Gui — Thu, 30 Jul 2026 13:59:58 GMT

Part Number: CC3551E
Other Parts Discussed in Thread: CC3501E

Dear TI Engineer,

Can you provide the reference design file of 2.4G+5G dual frequency PCB onboard antenna for CC3551E?

Bye the way, if we only use the 2.4G frequency band, did the RF_A pin which is used for the 5G frequency band be directly pulled down to GND through a resistor?

Thanks,

Best Regards

WL1807MOD: WL1807MOD Module RF Configuration Options

Lukáš Havránek — Thu, 30 Jul 2026 13:02:30 GMT

Part Number: WL1807MOD

Hello Texas Instruments support,

I'm an Application Engineer from Advantech Czech s.r.o. inquiring about configuration capabilities regarding the WL1807 module.
Could you please confirm whether there are any tools, test modes, or commands available for configuring the WiFi module’s RF parameters?

Specifically, we would like to know whether it is possible to configure:

RF band
Operating frequency or channel
Channel bandwidth
RF output power
Other relevant RF parameters

Please also let us know whether any special firmware, drivers, utilities, or documentation are required to access these settings.

Our goal is to meet the requirements for SRRC certification for our SmartFlex SR310 which uses the mentioned module.

Thank you in advance for your support.

Best regards,
Lukáš Havránek

CC3551E: CC355xE SWDIO/SWCLK GPIO Mapping Clarification: Reference Schematic vs Datasheet Table 5-2

Koushik Bhimavarapu — Wed, 29 Jul 2026 17:42:34 GMT

Part Number: CC3551E

Hello TI Support Team,

While reviewing the CC355xE datasheet and reference schematic, we noticed a discrepancy regarding the SWD interface pins and would appreciate some clarification.

In the CC355xE Reference Schematic, the SWDIO signal is connected to GPIO_7 and SWCLK is connected to GPIO_8. However, in the Signal Descriptions (Table 5-2) of the datasheet, neither SWDIO nor SWCLK appears to be associated with any GPIO functionality.

This has led to some uncertainty regarding the intended use of these pins.

Could you please clarify the following:

Are the SWDIO and SWCLK pins multiplexed with GPIO_7 and GPIO_8, respectively?
Can these pins be used as general-purpose I/O during normal operation, or are they dedicated exclusively to the SWD debug interface?
If GPIO functionality is supported, are there any restrictions, configuration requirements, or implications for debugging and device programming?
Could you explain the reason for the apparent discrepancy between the reference schematic and the datasheet signal description table?

The answer will help us determine whether any design changes are required in our hardware.

For reference, we have attached screenshots from both the reference schematic and the datasheet.

Thank you for your support.

Best regards,
Koushik.

CC2564C: Implementation of the Inverted F Antenna

Yousif Ibrahim — Wed, 29 Jul 2026 13:57:27 GMT

Part Number: CC2564C

Hello TI Team,

Can I get support with the following questions for the Inverted F Antenna on CC2564C.

Are there any specific requirements for the ground plane, such as pattern layout or keep-out area? Please provide details on the necessary settings.
I could not find any information regarding the courtyard in the specifications; please advise on the required courtyard dimensions.
Is a keep-out area required for the section outlined in red in the figure below? If so, please provide the dimensions and configuration details.

Thank You

CC3351: CC3351: cc33xx: ERROR FW is stuck, triggering recovery

Niklas Salminen — Wed, 29 Jul 2026 12:27:50 GMT

Part Number: CC3351
Other Parts Discussed in Thread: CC3300, EZURI-3P-SONATI351,

Hi,
We are trying to upgrade to the latest cc33xx 1.0.2.17 on CC3351.
ti-linux-kernel: ti-linux-6.12.y (5ae038766eda6647bee6dc52c88308a0a280878d)
cc33xx-linux-mpu-ports: for ti-linux-6.12.y (43502d1c6784e37b0624948a9d0394e30a244920)

The error message from driver initialisation
kernel: cc33xx_driver cc33xx.8.auto: Direct firmware load for ti-connectivity/cc33xx-nvs.bin failed with error -2
kernel: cc33xx: ERROR FW is stuck, triggering recovery
kernel: cc33xx: ERROR Fatal error during driver init, cannot recover
kernel: cc33xx: WARNING download INI params to FW command sending failed: -5
kernel: cc33xx: ERROR FW download failed

Devicetree is copied from k3-am62a7-sk-m2-cc3351 , see below

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include "k3-pinctrl.h"

&{/} {
wlan_lten: regulator-30 {
compatible = "regulator-fixed";
regulator-name = "wlan_lten";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_3v3_sys>;
gpios = <&exp1 4 GPIO_ACTIVE_HIGH>;
enable-active-high;
};

wlan_en: regulator-31 {
compatible = "regulator-fixed";
regulator-name = "wlan_en";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
vin-supply = <&wlan_lten>;
enable-active-high;
gpios = <&main_gpio0 71 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&wlan_en_pins_default>;
};
};

&main_pmx0 {
wlan_en_pins_default: wlan-en-pins-default {
pinctrl-single,pins = <
AM62AX_IOPAD(0x0124, PIN_INPUT, 7) /* (F22) MMC2_SDCD.GPIO0_71 */
>;
};

main_mmc2_pins_default: main-mmc2-default-pins {
pinctrl-single,pins = <
AM62AX_IOPAD(0x0120, PIN_INPUT_PULLUP, 0) /* (G22) MMC2_CMD */
AM62AX_IOPAD(0x0118, PIN_INPUT, 0) /* (H22) MMC2_CLK */
AM62AX_IOPAD(0x011C, PIN_INPUT_PULLUP, 0) /* () MMC2_CLKLB */
AM62AX_IOPAD(0x0114, PIN_INPUT_PULLUP, 0) /* (E20) MMC2_DAT0 */
AM62AX_IOPAD(0x0110, PIN_INPUT_PULLUP, 0) /* (F21) MMC2_DAT1 */
AM62AX_IOPAD(0x010c, PIN_INPUT_PULLUP, 0) /* (F20) MMC2_DAT2 */
AM62AX_IOPAD(0x0108, PIN_INPUT_PULLUP, 0) /* (G21) MMC2_DAT3 */
>;
};

main_wlirq_pins_default: main-wlirq-pins-default {
pinctrl-single,pins = <
AM62AX_IOPAD(0x0128, PIN_INPUT_PULLUP, 7) /* (E21) MMC2_SDWP.GPIO0_72 */
>;
};
};

&sdhci2 {
status = "okay";
bootph-all;
vmmc-supply = <&wlan_en>;
pinctrl-names = "default";
pinctrl-0 = <&main_mmc2_pins_default>;
bus-width = <4>;
non-removable;
ti,fails-without-test-cd;
cap-power-off-card;
keep-power-in-suspend;
ti,driver-strength-ohm = <50>;

#address-cells = <1>;
#size-cells = <0>;
wifi: cc33xx@2 {
compatible = "ti,cc3300";
reg = <2>;
pinctrl-names = "default";
pinctrl-0 = <&main_wlirq_pins_default>;
interrupt-parent = <&main_gpio0>;
interrupts = <72 IRQ_TYPE_EDGE_FALLING>;
};
};

Device firmwares from 1.0.2.17 package
~# md5sum /usr/lib/firmware/ti-connectivity/*
8932fcc91421435dd851ef1b34296733 /usr/lib/firmware/ti-connectivity/cc33xx-conf.bin
1f1cb95894cbf318141628eea13fa7c0 /usr/lib/firmware/ti-connectivity/cc33xx_2nd_loader.bin
10828049c2079c83b0ed69cf033bda3b /usr/lib/firmware/ti-connectivity/cc33xx_fw.bin

We are currently using 1.0.0.8 firmware release and drivers. We have also previously tried to upgrade from this release but unsuccessfully. During those times we have also noticed this same error messages. In conclusion, we know that 1.0.0.8 is working with our hardware so there could be some configuration issue with this recent one. Right now we are using inband IRQ with 1.0.0.8 and have also tried to exclude OOB irq from dts but to the same result.

CC3551E: Request for Support – High Initial Packet Loss at Wi-Fi 5 GHz / 5825 MHz

Jim Deng — Wed, 29 Jul 2026 09:44:03 GMT

Part Number: CC3551E
Other Parts Discussed in Thread: LP-EM-CC35X1

Subject: Request for Support – High Initial Packet Loss at Wi-Fi 5 GHz / 5825 MHz

Dear TI Support Team,

During RF production testing, we observed a high packet loss rate during the first Wi-Fi test at 5825 MHz. The details are as follows:

Issue Description:

The packet loss rate is high during the first test at 5825 MHz.
Under the same test conditions, the packet loss rate returns to normal during the second and subsequent tests.
The issue is reproducible and mainly occurs during the initial test.

Current Findings:

Our investigation indicates that the issue is strongly related to the SDK version.
With the previous SDK9 version, the initial packet loss rate was close to 100%.
After upgrading the SDK10 and applying related optimizations, the initial packet loss rate was reduced to approximately 30%.
The packet loss rate during the second and subsequent tests is normal.

Target:

We aim to reduce the initial packet loss rate to below 10% to meet our production test requirements.

Could you please help confirm the following?

Are there any known differences between SDK versions regarding Wi-Fi 5 GHz RF initialization, calibration, or 5825 MHz channel configuration?
Is any additional delay, RF calibration, warm-up procedure, or packet pre-transmission required before the first test?
Are there any recommended initialization procedures, patches, configuration parameters, or newer SDK versions that could improve the initial packet loss rate?
Is this a known issue in the current SDK?

We can provide the SDK versions, test commands, test environment, logs, and detailed test results if required.

Thank you for your support.