https://e2e.ti.com/support/wireless-connectivity/Products covered in this section are low power RF ICs and connectivity protocols such as ZigBee, RF4CE, Bluetooth & Bluetooth Low Energy, ANT, WLAN, SimpliciTI, ISO 15693/14443, and NFC.en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1648040/cc1314r10-cc1314r10-standby-current-consumption-significantly-higher-than-datasheet-specification---energytrace-measurement/6381730Sat, 13 Jun 2026 07:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:20e5a00c-ae91-4e38-ac4b-1ade24857cafDharani PrabhaHi Siri, Issues Fixed We encountered and resolved several issues during our power optimization journey. I have fixed the previously mentioned issue, which was caused by AONEventMcuWakeUpSet(AON_EVENT_MCU_WU0, AON_EVENT_RTC_CH0) being called during initialization. Before entering sleep, I was setting the compare value on RTC CH0 to wake up the MCU. Since both of these events were using CH0, the MCU was unable to enter deep sleep properly, resulting in a current consumption of approximately 1.08 mA. Commenting out the AONEventMcuWakeUpSet() call and using RTC CH0 exclusively for our application alarm resolved the issue completely. Current Application Design Flow Our wireless sensor application follows the state machine described below. On power-up, the MCU initializes the board, configures the AON RTC using CH0 for the application alarm, and opens the RF driver. It then enters the INIT state, where it initializes the RF, reads the device MAC address, and transitions to the JOIN_NETWORK state. In the JOIN_NETWORK state, the MCU tunes to a selected channel by calling RF_runCmd() with the CMD_FS frequency synthesizer command to program the RF frequency. It then listens for a gateway beacon, transmits a join request, and waits for a join response. Once the device joins the network, it enters the SLEEP state for 30 seconds. After successfully joining the network, the MCU transitions to the WAIT_FOR_CFG state, where it requests sensor configuration from the gateway. The configuration response contains the reporting interval and data collection interval, which are stored and used for subsequent sleep scheduling. Before entering sleep, the application cancels all pending RF commands using RF_cancelCmd() , waits for the cancellation to complete using RF_pendCmd() , yields the RF driver, and closes the RF handle using RF_close() . It then calls Power_sleep(PowerCC26XX_STANDBY) , allowing the MCU to enter true standby with a current consumption of approximately 0.0023 mA. Upon wakeup, the MCU reinitializes the RF driver, determines the next state based on timing, collects sensor data, updates the RF frequency using RF_runCmd() with CMD_FS , transmits the sensor data, receives the acknowledgement, and then returns to sleep for the configured reporting interval. This cycle repeats continuously. Current Observation We are pleased to report that, after applying the fixes described above, the standby current consumption is consistently 0.0023 mA across multiple wake-up cycles when only RF open and RF close operations are performed. The measured current values are as follows: Standby with no RF activity: 0.0023 mA After RF_open() only: 0.0023 mA After executing RF_runCmd() with CMD_FS : 1.08 mA // CMD_FS // Frequency Synthesizer Programming Command rfc_CMD_FS_t RF_cmdFs = { .commandNo = 0x0803, .status = 0x0000, .pNextOp = 0, .startTime = 0x00000000, .startTrigger.triggerType = 0x0, .startTrigger.bEnaCmd = 0x0, .startTrigger.triggerNo = 0x0, .startTrigger.pastTrig = 0x0, .condition.rule = 0x1, .condition.nSkip = 0x0, .frequency = 0x0362, .fractFreq = 0x0000, .synthConf.bTxMode = 0x0, .synthConf.refFreq = 0x0, .__dummy0 = 0x00, .__dummy1 = 0x00, .__dummy2 = 0x00, .__dummy3 = 0x0000 }; int wcs_prop_rf_set_freq_cmd(uint16_t u16_freq, uint16_t u16_fract_freq) { int ret_val = 0; RF_CmdHandle cmd_handle = RF_cancelCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, 0); if(cmd_handle >= 0) { RF_EventMask e = RF_pendCmd( rfHandle, cmd_handle, RF_EventLastCmdDone | RF_EventCmdCancelled | RF_EventCmdAborted |RF_EventCmdStopped); printf("RF cancel event = 0x%08X\n", (uint32_t)e); } /* Yield RF core -> powers down -> */ /* releases DISALLOW_STANDBY! */ RF_yield(rfHandle); /* Set the frequency */ RF_cmdFs.frequency = u16_freq; RF_cmdFs.fractFreq = u16_fract_freq; RF_cmdFs.startTrigger.triggerType = TRIG_NOW, // Force immediate execution //dharani - powOP RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0); //dharani - powOP g_freq_update_sts = RF_cmdFs.status; //dharani - powOP //Here event mask is set to 0. So no errors will be received return ret_val; } Using the sleep () or usleep () cause the MCU to be in Idle state means the MCU consumes 700 uA current approximately. Could you please help us understand why executing the CMD_FS command causes the standby current to increase to 1.08 mA, and suggest any additional steps required to return the device to the expected low-power state? Is there any driver API available to configure the RTC and use it as a wake-up source for the MCU from deep sleep? If so, could you please provide the recommended approach or any reference examples? Regards, Dharanihttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1654555/cc2642r-cc2642-issue-with-direct-rssi-acquisition-in-cc2642-connection-monitor-project/6381709Sat, 13 Jun 2026 02:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a8ab79df-fa87-468e-b1c9-2207c37a4562junjie DengSubject: BLE RSSI Acquisition & Connection Latency Question on simple_peripheral Project Dear TI Technical Support Engineer, Greetings. Our product adopts LIN bus for data transmission with each packet length fixed at 8 bytes. However, the BLE connection parameters occupy a minimum of 28 bytes, resulting in severe transmission latency. We intend to implement automatic, seamless active connection to mobile phones based on the simple_peripheral project, and have several questions to consult: Our intended scheme: Our central device sends the mobile phone MAC address to the simple_peripheral peripheral device, then the peripheral actively initiates a connection to the target mobile phone using this MAC address, and reads the phone's RSSI value. Core key question: Is it possible for the simple_peripheral device to successfully read the mobile phone RSSI value without any data interaction or data transmission with the connected mobile phone after establishing the BLE connection? Looking forward to your professional reply. Best regards, dengjunjiehttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1654555/cc2642r-cc2642-issue-with-direct-rssi-acquisition-in-cc2642-connection-monitor-project/6381697Sat, 13 Jun 2026 01:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8333f3f8-2ba1-4720-bb2f-893f377e2d60junjie DengDear TI Technical Support Engineer, Greetings, The timestamps from the two CC2642 devices are not synchronized. I would like to confirm whether adjusting the BUS LATENCY parameter after calculating the exact link latency of our connection can resolve this issue. If this approach is feasible, what is the maximum allowable error margin in milliseconds (ms)? Looking forward to your reply. Best regards, dengjunjiehttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1654547/cc3351-configuration-file/6381649Fri, 12 Jun 2026 22:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c6f98977-1b11-4c08-8872-4c081c24ed79Romain CazalisHi Josh, thanks for the advice. I have tried to do set_tx -default 0 but did not change anything. How much should I get on SMA connector with set_tx -tx_power 30 , phy.insertion_loss_2_4GHz = 0x00, 0x00 and phy.insertion_loss_2_4GHz = 0x00, 0x00 ? +20dBm? or less? Because I removed all components except one 100pF capacitor in series between diplexor output and the SMA connector and I still get +9dBm. I just tried with tx_start_tone and I get +12dBm. A bit better but still missing few dB. What am I missing? Romainhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1648714/cc3551e-uart-driver-write-issue/6381647Fri, 12 Jun 2026 22:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c8db7449-aa73-4d46-8da8-554f9236022dBLiuHello zhong wei, I didn't realize my message never sent out. Sorry to keep you waiting. I wanted to tell you that I did not follow your steps (since you were experimenting there anyway), and ultimately did not recreate your issue. I have attached my code and SYSCFG to this response. When hooking up the logic analyzer, I never saw a 7.5 ms delay, which you can see since my entire 256 byte transaction took place within the green block: I had 4 transactions (1 second delay in between) and none had any delay in the middle of a packet. I am open to your feedback. e2e.ti.com/.../uart2echo.syscfg /* * 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 "AS IS" * 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. */ /* * ======== uart2echo.c ======== */ #include #include /* Driver Header files */ #include #include /* Driver configuration */ #include "ti_drivers_config.h" /* * ======== mainThread ======== */ void *mainThread(void *arg0) { char input[] = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; const char echoPrompt[] = "Echoing characters:\r\n"; UART2_Handle uart; UART2_Params uartParams; size_t bytesRead; size_t bytesWritten = 0; int_fast16_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 a UART where the default read and write mode is BLOCKING */ UART2_Params_init(&uartParams); uartParams.baudRate = 921600; uart = UART2_open(CONFIG_UART2_0, &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); UART2_write(uart, echoPrompt, sizeof(echoPrompt), &bytesWritten); /* Loop forever echoing */ while (1) { // bytesRead = 0; // while (bytesRead == 0) // { // status = UART2_read(uart, &input, 1, &bytesRead); // if (status != UART2_STATUS_SUCCESS) // { // /* UART2_read() failed */ // while (1) {} // } // } // bytesWritten = 0; // while (bytesWritten == 0) // { status = UART2_write(uart, &input, 256, &bytesWritten); if (status != UART2_STATUS_SUCCESS) { /* UART2_write() failed */ while (1) {} } sleep(1); // } } }https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1649245/cc3351-mcu-sdk-prer9-ble-ready-event/6381595Fri, 12 Jun 2026 21:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d492c5be-d2e0-4036-b34e-41c74c32669eJosh PrushingHi Gaétan, I wasn't able to fully look into this today, but I do think with the way the R9 release is configured, you shouldn't need to use the Zephyr BT stack to parse the HCI event. I imagine there is just something else that needs to be enabled in the Zephyr configuration, I'll continue to look into this. I imagine this will be related to the drv function in the /drivers/bluetooth/hic/hci_ti_cc3xxx.c file. In addition, if the pre-R9 release was working, is it possible to use that version in the meantime? Best Regards, Josh Prushinghttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1643864/cc3351-firmware-doesn-t-reboot-after-crash/6381558Fri, 12 Jun 2026 21:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:355fa49a-70a4-4e86-b8d6-b745f0d660d6Josh PrushingHi Gaétan, Here's the link to the hal_ti, but this should be configured when calling west: https://github.com/TexasInstruments/simplelink-hal_ti/releases/tag/218d961-ti-9.22.00_ea If you're seeing that it isn't configured on CC33xx implementation, I'll look into it deeper. Best Regards, Josh Prushinghttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1654539/cc2745r10-q1-channel-sounding-function-not-returning-value/6381552Fri, 12 Jun 2026 21:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:85dc1c8e-28df-4ee5-afd3-282eb6a1bfeaJosh AldersonHello, It sounds like it could be a power issue. The voltage might be fine; have you checked the current consumption while using the debugger and running channel sounding? If you haven't already, I suggest checking the current draw/power consumption when using the debugger and check if the coin cell is able to supply that much current/power. Best, Josh Aldersonhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1653679/cc3501e-matter-stack-size-for-various-use-cases/6381530Fri, 12 Jun 2026 20:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:003af314-41f0-4bcb-9720-a803f91273ceABBlake, I am working on these, will get back to you soon.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1654498/cc3301-wlan_set_macaddress-has-no-effect/6381518Fri, 12 Jun 2026 20:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a4f4c367-9925-4db5-b6d1-e338a6a0a8e1ABHi Austin, Can you please attach some radio FW logs (see https://dev.ti.com/tirex/explore/content/simplelink_wifi_sdk_10_10_01_08/docs/WiFi-toolbox/html/WiFi-toolbox/logger_user_guide.html# ) Do both sequences and record the logs, this should tell us what is happening on the radio sub system.https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1654547/cc3351-configuration-file/6381512Fri, 12 Jun 2026 20:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1a767196-f15b-422d-99d9-27986835964cJosh SmithHi Romain, I want to break this down into two sections: Wi-Fi Commands - Can you send me the exact command sequence you are using for just wi-fi? Have you tried to call the set_tx -default 0 before configuring specific parameters such as -tx_power and -delay? Can you follow this command follow and tell me your output: calibrator wlan0 cc33xx_plt tune_channel 2 0 0 calibrator wlan0 cc33xx_plt set_manual_calib -tx 1 -rx 1 calibrator wlan0 cc33xx_plt set_tx -default 0 calibrator wlan0 cc33xx_plt set_tx -tx_power 30 -delay 50 calibrator wlan0 cc33xx_plt start_tx Conf Commands Your understanding on the insertion loss parameter is correct. The insertion loss parameter works with the Power Limit Array to ensure you see the desired output power defined in the Power Limit Array. For example, if 15dBm is set in the PLA with an insertion loss of 3dB, the device will compensate for the 3dB of loss by transmitting at 18dBm at the device pin to ensure that 15dBm is seen at the SMA. Please ensure the correct insertion loss from IC pin to SMA is correctly measured and included in the CONF file. You can use our Simplelink Wi-Fi Toolbox's INI Composer Tool to generate a new conf with your measured values Let me know how this works. Joshhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1655086/cc2340r5-high-current-in-lpn-nodeFri, 12 Jun 2026 20:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cce65b09-9d62-42db-b8a9-37d52df1d677Michael OstrovskyPart Number: CC2340R5 We measure high curret ~200uA in lpn provisioned node when device should be in the standby mode. No pereferals just buttons. If provisioned lpn node powers up and friend nodes are not available there a very long time it is staying in active mode trying to find friend node.CC2340R5Applianceshttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1653992/tmux6119-voltage-drop-issue/6381372Fri, 12 Jun 2026 18:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d117b6e7-acc3-4702-b737-ef82e49032c4Caroline OrmondHello Jason, Are you able to probe the supply current? With the voltage drop you described, I would expect a much smaller current around 33 mA. Best, Carolinehttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1655053/cc2500-firmware-example-using-cc2500/6381335Fri, 12 Jun 2026 17:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e9d3a9ab-664c-438e-8355-a336aad16316Ryan Brown1Hi Atilano, Please refer to the Software Development section of the product page. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1655053/cc2500-firmware-example-using-cc2500Fri, 12 Jun 2026 16:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d5a0cded-dd23-4990-af20-d5321fa55328Atilano ValadezPart Number: CC2500 Could you please provide a firmware example demonstrating how to use the CC2500 transceiver?CC2500https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1655047/cc113l-cc113l-gdo0-output-pulse-truncation-in-async-mode-at-low-signal-levelFri, 12 Jun 2026 16:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5322e616-ff82-416e-9484-2a8ce4b7c6b5lilian MUAKA BALUPart Number: CC113L We are using the CC113L in asynchronous serial mode to demodulate a signal with the following RF characteristics: - Modulation: FSK - Frequency: 433.9085 / 433.9315 MHz - Baud rate: 11,363 baud - Expected 1T pulse width: 88 µs CC113L configuration (relevant registers): - IOCFG0 = 0x0D (GDO0: serial data output, asynchronous mode) - PKTCTRL0 = 0x32 (asynchronous serial mode, no CRC, infinite packet length) - BSCFG = 0x0C - AGCCTRL2 = 0x47 - AGCCTRL1 = 0x40 - AGCCTRL0 = 0x91 - FOCCFG = 0x00 (FOC disabled) - FREQ = 0x10B071 (~433.92 MHz) - MDMCFG4 = 0xC9 (CHANBW ~101 kHz) - DEVIATN = 0x45 Observed issue: At low signal levels (−97 dBm), the GDO0 output pulse width is approximately 25 µs instead of the expected 44 µs (1T at 11,363 baud). The signal appears to be truncated only on the high-level pulses. At a nominal signal level (−86 dBm and above), the GDO0 timing is correct. Oscilloscope captures are available, showing the correct waveform with RF generator (44 µs pulse in blue) compared to the degraded waveform on GDO0 (25 to 46 µs pulse in yellow) at a low signal-to-noise ratio. Which parameter affects the timing of the GDO0 output in asynchronous mode at a low signal-to-noise ratio? Thank you for your support.CC113Lhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1654547/cc3351-configuration-file/6381219Fri, 12 Jun 2026 16:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:64bf89a7-c32a-48f2-8860-d33172d01270Romain CazalisHi Josh, thanks for your quick answer. I am attempting Wifi transmissions. I have another post where I have trouble with BLE. We are currently working on it but this new post is only related to Wifi. I do follow all the documentation on manufacturing commands but still can't get more than +9dBm. Everything else works. I can change channel, modulation, datarate, switch from 2.4GHz to 5GHz... my only problem is max TX power limited to +9dBm. I have looked at my hardware but can't see anything wrong so far. What happens if I set phy.insertion_loss_2_4GHz = 0x3F, 0x3F Is there some kind of compensation to increase TX power up to +7.875dB? Same question with phy.ant_gain_2_4GHz = 0x40, 0x40 Is there some kind of compensation by +8dB? But I am sure there must be some hardware limit that the CC3351 can't go over. So the question is : With phy.insertion_loss_2_4GHz = 0x00, 0x00 and phy.insertion_loss_2_4GHz = 0x00, 0x00 is the CC3351 at its max TX power or are there settings to get few more dB output? Romainhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1637746/cc2564c-anomalous-le-disconnections-when-advertise-is-enabled/6381187Fri, 12 Jun 2026 15:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cfa8f08a-cea9-4948-837b-a096cddc00d3BLiuCan you also provide firmware logs as explained here? www.ti.com/.../swau058d.pdfhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1637746/cc2564c-anomalous-le-disconnections-when-advertise-is-enabled/6381178Fri, 12 Jun 2026 15:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8346c69a-eac8-4ffa-9be1-b0e824efd104BLiuHi Mir, Quite interesting. I reached this step: [quote userid="596383" url="~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1637746/cc2564c-anomalous-le-disconnections-when-advertise-is-enabled/6381152"]- unsubscribe from the CCCD[/quote] Then I wrote to and read from 0xBA04C4B2-892B-43BE-B69C-5D13F2195392 (TX credits characteristic) via the LightBlue app but not continuously. I sort of just spammed the reads and writes as frequently as possible and did not see any disconnects. I will look into a way to "spam" at a faster rate to the point where it's nearly continuous. I hope this data point can get us closer. Do you still see the disconnect issue when you lower the frequency that you read and write to the characteristic?https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1637746/cc2564c-anomalous-le-disconnections-when-advertise-is-enabled/6381152Fri, 12 Jun 2026 15:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4f59df4d-4298-44d9-9078-33c2298d34baMir AHi, about the CSRK keys, I think I'm not using those. As far as I understand, the printout in the log after the "Pairing Request: PHONE_BDADDR" lists what keys the connected phone supports. In my code the ConfigureCapabilities() function is identical to the one in the SPPLEDemo.c that you sent me: /* The following function provides a mechanism to configure a */ /* Pairing Capabilities structure with the application's pairing */ /* parameters. */ static void ConfigureCapabilities(GAP_LE_Pairing_Capabilities_t *Capabilities) { /* Make sure the Capabilities pointer is semi-valid. */ if(Capabilities) { /* Configure the Pairing Capabilities structure. */ Capabilities->Bonding_Type = LE_Parameters.BondingType; Capabilities->IO_Capability = LE_Parameters.IOCapability; Capabilities->MITM = LE_Parameters.MITMProtection; Capabilities->OOB_Present = LE_Parameters.OOBDataPresent; Capabilities->SC = LE_Parameters.SC; Capabilities->Keypress = LE_Parameters.Keypress; Capabilities->P256DebugMode = LE_Parameters.P256DebugMode; /* ** NOTE ** This application always requests that we use the */ /* maximum encryption because this feature is not a */ /* very good one, if we set less than the maximum we */ /* will internally in GAP generate a key of the */ /* maximum size (we have to do it this way) and then */ /* we will zero out how ever many of the MSBs */ /* necessary to get the maximum size. Also as a slave */ /* we will have to use Non-Volatile Memory (per device */ /* we are paired to) to store the negotiated Key Size. */ /* By requesting the maximum (and by not storing the */ /* negotiated key size if less than the maximum) we */ /* allow the slave to power cycle and regenerate the */ /* LTK for each device it is paired to WITHOUT storing */ /* any information on the individual devices we are */ /* paired to. */ Capabilities->Maximum_Encryption_Key_Size = GAP_LE_MAXIMUM_ENCRYPTION_KEY_SIZE; /* This application only demonstrates using Long Term Key's (LTK) */ /* for encryption of a LE Link, however we could request and send */ /* all possible keys here if we wanted to. */ Capabilities->Receiving_Keys.Encryption_Key = TRUE; Capabilities->Receiving_Keys.Identification_Key = FALSE; Capabilities->Receiving_Keys.Signing_Key = FALSE; Capabilities->Sending_Keys.Encryption_Key = TRUE; Capabilities->Sending_Keys.Identification_Key = FALSE; Capabilities->Sending_Keys.Signing_Key = FALSE; } } About the PeriodicTxTask() that you sent me, I've tried it, and I'm not getting any disconnections. Also, I can confirm that in that same setup, if start again to read and write, I get the disconnection. The sequence was: - connect the phone to the device - activate bond - subscribe to the CCCD to enable the data sending every 50ms from the PeriodicTxTask() - re enable advertise on the device - wait 45 minutes, and there were no anomalies - unsubscribe from the CCCD - start to write to and read from the SPPLE TX characteristic, continuously (note that I didn't disconnect and reconnect phone and device) - after around 3 minutes I had the anomalous disconnection with reason 0x3D So, looks like we are narrowing the problem. If you are having trouble to perform the write from your phone, perhaps you could use two demo boards, one set as SERVER and the other as CLIENT. From what I've seen in my "real" application, the issue should manifest also in that situation.