https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1646641/cc1311p3-cc1311p3-unable-to-decode-2-fsk-signal-at-19-2-ksps-with-2-khz-deviation/6361163Wed, 27 May 2026 18:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7f65d60c-53fd-440c-ae45-bd47e08abb61Theiv BEven with your suggested bandwidth configuration, we are observing intermittent RF data miss mostly on higher data size like 100/500/1024bytes cases, but we have seen some more consistency(less data miss) on lower data size like 34 byte case, Could you please help us understand what could be the reason for the mentioned behaviour. ? Let me know if you need any sequence which we followed for continuous RX mode. Thanks, Theiv B.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649883/cc1352r-how-to-program-a-cc1352r-using-serial-bootloader/6360958Wed, 27 May 2026 15:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:92bdc8cc-a068-47be-926d-d467f07080d2Bill GarlandThanks Daniel, I found a couple of problems that i hoped would fix it without luck: There was no pullup on the switch connected to my BL_PIN_NUMBER pin I had used the pin number rather than the DIO number My BL_PIN_NUMBER is connected to DIO 8 which now has a pullup. My CCFG is C5 08 FE C5. I tried changing FE to FF but no joy. The code runs on a Launchpad and I have taken the hex file to program my board Any more ideas?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649883/cc1352r-how-to-program-a-cc1352r-using-serial-bootloader/6360883Wed, 27 May 2026 15:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f1e28fea-0fb7-4ce7-9e84-5f64e2456111Daniel Guarecuco AguiarHi Bill, The following application notes guides you through the serial bootloader process: https://www.ti.com/lit/an/swra466e/swra466e.pdf I would recommend you don&#39;t manually edit the CCFG manually as you could brick the device if you set the incorrect values. Instead, enable the bootloader and the bootloader backdoor pin with SysConfig Have you set a backdoor pin? If you can keep flashing the device and it doesn&#39;t boot, this would be because there is no valid image or the backdoor pin is being kept triggered. Does the exact same process and image work with the Launchpad? Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649883/cc1352r-how-to-program-a-cc1352r-using-serial-bootloaderWed, 27 May 2026 13:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4df5948c-2ddc-4504-abbe-6400354eb25fBill GarlandPart Number: CC1352R Other Parts Discussed in Thread: UNIFLASH , SYSCONFIG I am trying to develop a new product using a CC1352R. I have used code composer to build the rfEchoTx example and this runs on the CC1352R LaunchPad. My new PCB only has access to the serial RX and TX lines. Using the TI UniFlash I can program the board with the hex file created in CCS but it does not run. I have manually progammed the CCFG (uising TI Flash Progemmer 2) so I can get back to the bootloader should my program ever run. Have I missed out a step in creating a valid .hex file compatible with the serial bootloader? BillUniFlashCC1352RSYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649628/cc1312r-1ma-generation-in-standby-mode/6360461Wed, 27 May 2026 09:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e537ed44-5e71-4bbd-9b8b-a13467241b95Daniel Guarecuco AguiarHi Shingo, Could you explain what&#39;s on the plot? Are the dots marking when your device wakes up? They are spaced about 30-40 min rather than 2-7 min. So not sure if I&#39;m interpreting properly. The 1 mA stage, you say happens regularly every 12 h? And it stays at 1mA for almost 3h? Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649152/cc1311p3-cc1311p3-clarification-on-narrowband-mode-impact-on-tx-occupied-bandwidth-obw/6360388Wed, 27 May 2026 09:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b0bdd5e2-49c1-4e6b-8d4d-c337695434fdTheiv BHI TI team, Any update on my query ?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1636875/cc1310-turbo-oad-crc-failed/6360086Wed, 27 May 2026 06:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ad288501-8b91-4d4c-908f-ac6ba7d1e244faker wangHi Daniel, I have tested it and it has indeed been resolved. Thank you Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649628/cc1312r-1ma-generation-in-standby-modeWed, 27 May 2026 02:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:954cbbee-4c4e-4aab-85e7-09462f3f0fe5shingo sezakiPart Number: CC1312R I&#39;ve noticed a pattern in the timing of the 1mA current generation. The wake-up time in AON_RTC has been changed from 8 hours to 2-7 minutes. Is this possible in relation to AON_RTC? I&#39;ve attached the current graph.Datacom moduleCC1312Rhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1646641/cc1311p3-cc1311p3-unable-to-decode-2-fsk-signal-at-19-2-ksps-with-2-khz-deviation/6358580Tue, 26 May 2026 13:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4261fbdc-5f10-45ba-b69d-4ded93d57d34RGWHi, The Rx bandwidth is too tight with the data rate of 19.2 kbps. The narrowband Rx bandwidth in SmartRF studio is 17.1 kHz for a datarate of 9.6 kbps and 2.4 kHz fdev; this signal has a bandwidth of 14.4 kHz with a 0 ppm crystal or TCXO. Increasing the datarate to 19.2 kbps and fdev with 4.8 kHz; makes the signal bandwidth 28.8 kHz with a 0 ppm crystal or TCXO. Your Rx bandwidth is 24.5 kHz which can be too small. Can you increase this? Regards, Richardhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1646641/cc1311p3-cc1311p3-unable-to-decode-2-fsk-signal-at-19-2-ksps-with-2-khz-deviation/6358551Tue, 26 May 2026 12:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6bc4536b-462c-4828-99f5-4a434044cbd9Theiv BHi TI Team, We are continuing our investigation on the intermittent RX data miss issue observed on CC1311P3. Current RF configuration: Modulation : 2-FSK / GFSK Data Rate : 19.2 ksps Frequency Deviation : 4.8 kHz RX Filter Bandwidth : 24.5 kHz RX Mode : Partial read buffer mechanism enabled Observation: Even with the above relaxed deviation and RX bandwidth settings, we are still observing random data miss / packet corruption intermittently at the receiver side. Additional observations: The issue is not consistently reproducible across all boards. Some boards show higher miss probability compared to others. The behavior varies board-to-board under the same RF configuration. Current software flow: On RF_EventRxEntryDone, we post a message to a task context. The task then reads the partial data and forwards it through UART. Questions: Could this behavior be related to RF core timing constraints while using partial read RX mode at 19.2 ksps? Is there any known limitation on interrupt latency or task scheduling latency for partial RX buffer handling? Can delayed processing of RF_EventRxEntryDone lead to FIFO overrun or missed symbols internally in the RF core? Are there any recommended timing constraints or best practices for UART handling while using partial RX reads? Since the issue varies board-to-board, could RF calibration tolerance, clock accuracy, or RX chain sensitivity variation contribute to this behavior? Please let us know if there are any RF statistics, debug signals, or internal counters that can help isolate whether the issue is due to RF timing, software latency, or symbol synchronization loss. Thanks, Theiv Bhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1645055/cc1125-cc1125-sleep-current-rises-to-2ma/6358460Tue, 26 May 2026 11:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4210ca35-236d-433b-836f-f7fc04b4abedAndy NeilThe problem seems to be that, in its low-power STANDBY mode, the STM32F0 outputs are hi-Z - and the CC1125 does not like this. If I use the STM32F0&#39;s STOP mode instead, and set the used outputs to be all high (or low), I get down to 5.6uA for the Nucleo + BOOSTXL-CC1125. From the CC1125 point-of-view, is there any advantage to choosing to force the outputs low or high? PS - for completeness : I did try just enabling the STM32&#39;s pullups when in its STOP mode - and got down to 120uA. STM32F0 pullups are typically 40kΩ; max 55kΩhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1646250/cc1352p-ti-synchronous-serial-interface-example/6358254Tue, 26 May 2026 08:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e97ff459-36a8-41f4-8489-fd6c5554c605Arthur R☑️Hi Jacky, In which case, the example is here: spicontroller.c However, it is configured to use SPO=0, and SPH=1 by default. To change that, edit the line here: spiParams.frameFormat = SPI_POL0_PHA1; to the following spiParams.frameFormat = SPI_POL0_PHA0; Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1649152/cc1311p3-cc1311p3-clarification-on-narrowband-mode-impact-on-tx-occupied-bandwidth-obwTue, 26 May 2026 05:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7154291c-cc98-4851-9ecb-7a6ca3930bdfTheiv BPart Number: CC1311P3 We are evaluating the CC1311P3 for a 25 kHz narrowband 2-FSK system with the following approximate configuration: Modulation: 2-FSK Symbol Rate: 19.2 kbps Modulation Index: ~0.45 to 0.5 Frequency Deviation: ~4.3 kHz Channel Bandwidth: 25 kHz We would like clarification regarding the “Narrowband Mode” option in SmartRF Studio / CC1311P3: What is the exact purpose of enabling “Narrowband Mode” in the modem configuration? Is Narrowband Mode applicable only to the Rx path, or does it also modify the Tx modulation/filtering behavior? For a modulation index close to 0.5 in 2-FSK systems, is enabling Narrowband Mode recommended? We observed that enabling Narrowband Mode increases the measured Occupied Bandwidth (OBW) at the transmitter output. Could you please explain why this occurs? Does Narrowband Mode alter any of the following internally? Tx pulse shaping/filtering Modulation shaping Frequency deviation scaling Demodulator bandwidth IF/Rx filtering For achieving minimum OBW while maintaining good sensitivity and demodulation robustness in a 25 kHz channel, would TI recommend enabling or disabling Narrowband Mode for this PHY? Thanks, Theiv BCC1311P3https://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/6358051Tue, 26 May 2026 05:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:78a90b00-5166-4be4-95d1-99d0b2fb0e48SiriWhat you are seeing is the recharge current. Please see https://www.ti.com/lit/swra478 for more details. In the original empty project the MCU wake up every 1 s, and your mean current consumption is about 6.1 uA. Changing the sleep time to for example 100 s, the mean current consumption will be about the 1.4 uA BR Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1646250/cc1352p-ti-synchronous-serial-interface-example/6356959Mon, 25 May 2026 01:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3dab3138-8b58-40b2-b6ab-0e9d369e8782Jacky HungHi Arthur, I mean SSI interface example as below pic, the i2ctmp example look like i2c not ssi interface. CONFIG_I2C_TMP - I2C bus used to communicate with the TMP sensor thanks Jackyhttps://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/6356060Fri, 22 May 2026 12:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6c7dc285-9e70-4afc-9c53-89e4e9580c2eDharani PrabhaThank you for your prompt response and guidance regarding the CC1314R10 standby current measurement procedure. I have carefully followed all the recommended steps mentioned in your previous response. However, I am still observing a higher-than-expected current consumption. And could you suggest me the reason for frequent wake up of the MCU even though i am running the empty code? I would like to provide a detailed update on my findings and request further assistance. Regards, Dharanihttps://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/6354045Thu, 21 May 2026 08:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:81dd54d8-863c-4f9b-914a-d4186cafcfe5SiriPlease start by testing the current consumption running a known good example from the SDK. I took the empty example, and ran it without modifications. The current consumption in Standby is so low that you are not even able to measure it with EnergyTrace. I have removed the jumpers to the LEDs I ran the code on a LP_EM CC1314R10 + LP_XDS110ET. Please remember to calibrate ET by power cycle the boards after you have launched energyTrace. BR Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1647822/cc1352r-bootloader-error-with-uniflash/6353958Thu, 21 May 2026 07:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:39b91c64-eca5-4931-a598-37b45629bc60Arthur R☑️Hi Marc, This tool does not support intelhex.You have to generate a binary file, in the same format has the last comment on this post: [FAQ] CC1352P7: Is ti-wisunfantund working with the newly released BeaglePlay? (yes) - Sub-1 GHz forum - Sub-1 GHz - TI E2E support forums . CCFG must be excluded only if you are using the CC1354. Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1647822/cc1352r-bootloader-error-with-uniflash/6353957Thu, 21 May 2026 07:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f5dab688-d7a5-4ef2-b354-c6d8a1ca05b8Marc MartinI checked the HEX generation command. CCS is running: tiarmhex --romwidth=32 --intel -o onehop.hex onehop.out However, the alternative bootloader tool still reports: &quot;WARNING! Bootloader is disabled in the new CCFG&quot; If I continue, erase fails at 88% with: &quot;Status 0x43 = INVALID_ADR&quot; Could you confirm whether this tool fully supports Intel HEX images with CCFG for CC1352R1F3, or whether the image must exclude the .ccfg section and keep the existing CCFG on the target?https://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-measurementThu, 21 May 2026 07:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:36a5ee58-8f53-4a92-b55b-69f8d2213974Dharani PrabhaPart Number: CC1314R10 Other Parts Discussed in Thread: , ENERGYTRACE , LP-XDS110ET , SYSCONFIG Hi Team, Device: Texas Instruments CC1314R10 LaunchPad: LP-EM-CC1314R10 Debugger: LP-XDS110ET (EnergyTrace™ Technology) SDK: simplelink_cc13xx_cc26xx_sdk_8_31_00_11 SDK IDE: Code Composer Studio - Version: 12.8.0.00012 I am attempting to measure the standby current consumption of the CC1314R10 MCU in isolation. According to the datasheet (SWRS270B), the expected standby current for 256 KB RAM retention with cache retention disabled and XOSC_LF clock source is approximately 1.08 &#181;A . However, EnergyTrace is consistently reporting a mean current of approximately 0.79 mA , which is approximately 730&#215; higher than the datasheet specification. HARDWARE SETUP: LP-EM-CC1314R10 LaunchPad (target) LP-XDS110ET (debugger + EnergyTrace) Powered via USB through LP-XDS110ET R24 and R25 removed to disconnect external flash MX25R1635F power supply No external sensors connected No I2C/SPI peripherals connected MEASUREMENT METHOD: EnergyTrace™ Technology via CCS EnergyTrace Profile -&gt; Live view Reading Current Mean value Measurement duration: continuous Board powered via LP-XDS110ET USB For System configuration, I have attached the document below which has the sysconfig snapshot in it. Device Config info.docx Below is the baremetal code used for the MCU energy estimation: int main(void) { /* Initialize board */ Board_initGeneral(); /* Configure all 46 GPIO pins as input */ for (int i = 0; i &lt; USED_PIN_COUNT; i++) { GPIO_setConfig(g_used_pins[i], GPIO_CFG_INPUT); /* * NOTE: GPIO_CFG_INPUT configured WITHOUT * pull-down — pins may be floating! * Should this be: * GPIO_CFG_INPUT | GPIO_CFG_PULL_DOWN_INTERNAL? */ } /* Release standby constraint */ Power_releaseConstraint(PowerCC26XX_DISALLOW_STANDBY); while (1) { Power_sleep(PowerCC26XX_STANDBY); } } Questions: Q1) Is GPIO_CFG_INPUT without pull-down causing floating input leakage? Should it be: GPIO_CFG_INPUT | GPIO_CFG_PULL_DOWN_INTERNAL? Q2) Both Calibrate RCOSC_LF and RCOSC_HF are enabled. Since LF XOSC is used, is RCOSC_LF calibration causing unnecessary periodic wakeups? Should Calibrate RCOSC_LF be disabled? Q3) Is EnergyTrace accurate enough to measure sub-&#181;A standby currents? Is the Live profile mean value the correct metric for standby measurement? Or should a specific time window be selected? Q4)Does the LP-XDS110ET debugger connection add any current overhead to the measurement? Thank you for your time and assistance. Any guidance on achieving the expected 1.08 &#181;A standby current would be greatly appreciated. Warm Regards, Dharaniprabha PEnergyTraceLP-EM-CC1314R10LP-XDS110ETCC1314R10SYSCONFIG