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/1676455/cc1352r-dmm-support-in-rtls-responder/6477728Wed, 09 Sep 2026 11:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0286cb9b-45e2-4a71-b346-7530fa04824cRSSATHEESH KUMARI updated the RF data transmission in the firmware with USE_PERIODIC_ADV and RTLS_CTE disabled. With this configuration, the Tag is able to successfully transmit both Basic BLE and RF data. Please refer to the attached screenshot for the test results. However, the Tag gets stuck only when USE_PERIODIC_ADV and RTLS_CTE are enabled in the firmwarehttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1678670/sysconfig-ccs-sysconfig-looses-pin-definitions/6477465Wed, 09 Sep 2026 08:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:05c371ed-4c5f-441c-b7c7-c95cb504dc2fArthur R☑️Hi Gullik, If you wish, you can share a project that reproduces the issue so that we can look at it. Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1680349/cc1312r-inquiry-for-sub-ghz-and-dual-band-wireless-mcus-and-modules/6477308Wed, 09 Sep 2026 05:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8cb17f30-41b6-443b-9549-7ec9bed1ad17SiriThis has already been answered here: (3) CC1312R: Inquiry for Sub-GHz and Dual-Band Wireless MCUs and Modules - Sub-1 GHz forum - Sub-1 GHz - TI E2E support forumshttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1676455/cc1352r-dmm-support-in-rtls-responder/6476492Tue, 08 Sep 2026 17:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:16c09e83-d8b2-4087-bdb5-3720bda1ddf3Tarek DHello, When you tested basic_ble, was DMM enabled? Best Regards, Tarek Dhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1680491/cc1310-input-impedance-of-the-cc1310-rx-differential-portTue, 08 Sep 2026 17:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:34a19345-5f2f-4cce-b5b3-604ef15bfd1eDan HuangPart Number: CC1310 Hi Support team , Could you provide input impedance value of the CC1310 RX differential port ? Since we need this information for design our own balun. Thanks .CC1310https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1680356/cc1312r-inquiry-for-sub-ghz-and-dual-band-wireless-mcus-and-modules/6476058Tue, 08 Sep 2026 14:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:394435b2-cbf2-4f6d-8157-818354a9fc9aSystem EngineerTirthal, we have a third party page on the web, have a look here first. We&#39;re happy to help if you have further questions. https://www.ti.com/sitesearch/en-us/docs/universalsearch.tsp?langPref=en-US&amp;nr=10&amp;searchTerm=%00&amp;preFilter=products_Wireless%20connectivity;designResourceProvider_Partner%20companies#cf-designResourceProvider=Partner%20companies&amp;cf-products=Wireless%20connectivity,Long%20range%20Sub-1%20GHz%20products Regards Svein Vettihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1680422/lp-xds110et-lp-xds110et-gpio-configuration-and-readback-remain-0x00-using-dbgjtagTue, 08 Sep 2026 13:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:65e852ce-f2e1-4956-863b-0b54e9609026ps-rajatPart Number: LP-XDS110ET Other Parts Discussed in Thread: MSP432E401Y Hello TI Team, I am trying to control GPIO1 and GPIO2 on an LP-XDS110ET using dbgjtag, initially testing the outputs with a multimeter. From the LP-XDS110ET schematic, I understand that: - GPIO1 connects to MSP432E401Y PF1 and appears at P10 pin 18. - GPIO2 connects to PF2 and appears at P10 pin 16. - PJ0 and PJ1 control the corresponding level-shifter directions. I tried the following commands, selecting the probe by its USB serial number: # Both HIGH ./dbgjtag -f @xds110 -V apply,SEPK.POD_SERIAL=LS42094H \ -Y gpiopins,config=0x6,write=0x6,mask=0x6,read=yes # Both LOW ./dbgjtag -f @xds110 -V apply,SEPK.POD_SERIAL=LS42094H \ -Y gpiopins,config=0x6,write=0x0,mask=0x6,read=yes Here, dbgjtag is run from the CCS ccs_base/common/uscif directory. I used mask 0x06 assuming command bits 1 and 2 correspond to GPIO1 and GPIO2; please confirm whether that mapping is valid. The commands complete without an error, but both HIGH and LOW requests report: The user GPIO pin config is 0x00. The user GPIO pin input is 0x00. Repeating HIGH → LOW → HIGH produces the same result at every step. I have not verified successful physical output switching. I reproduced this on two bench probes running firmware 3.0.0.41. A separate locally connected LaunchPad XDS110 running firmware 3.0.0.43 also returns the same zeros. The reported hardware IDs are 0x23 for the bench probes and 0x29 for the local probe. Could you please clarify: 1. Does LP-XDS110ET factory firmware support GPIO1/GPIO2 control through dbgjtag -Y gpiopins? 2. What are the correct configuration and mask values? 3. Does this command automatically configure PJ0/PJ1 for output through the level shifter? 4. What P9/LS_VDD configuration is required for a standalone multimeter test? 5. If this functionality is currently unsupported, is there a firmware fix or supported workaround? Thank you.Advanced Driver Assistance Systems (ADAS)LP-XDS110ETMSP432E401Yhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679686/cc1350-cc1350-launchpad-rev-1-2-schematic-and-bom/6475971Tue, 08 Sep 2026 12:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8ae272a6-094c-4a49-81af-dce1f1bfe617desouzaHi, The previous known schematic for this board only has differences in the Sub-1GHz RF path, which I copy below. The 2.4GHz path is identical. Hope this helps, Rafaelhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1680356/cc1312r-inquiry-for-sub-ghz-and-dual-band-wireless-mcus-and-modulesTue, 08 Sep 2026 10:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d90ac459-d825-4ee5-86b2-2ce62b000012Tirthal PatelPart Number: CC1312R We are currently evaluating wireless connectivity solutions for an upcoming low-power wireless device and are looking for suitable Wireless MCUs and ready-to-use wireless modules . We are primarily looking for: 1. Sub-GHz Wireless MCUs &amp; Modules Support for the 868 MHz band Low power consumption Long-range communication Suitable for IoT applications 2. Dual-Band Wireless MCUs &amp; Modules Support for 868 MHz Sub-GHz Additional support for 2.4 GHz Low power consumption Compact size Long-range communication Suitable for IoT applications Could you please recommend suitable products from your current portfolio and provide the following information? Complete part number Datasheet/product information Package/module dimensions and antenna options Development kit availability Product lifecycle and minimum 5-year availability/EOL support MOQ and lead time Unit pricing at 10K and 100K quantities We would appreciate your recommendations for suitable Sub-GHz and dual-band Wireless MCUs and modules , along with the above technical and commercial information. Thank you, and we look forward to your response.CC1312Rhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1680349/cc1312r-inquiry-for-sub-ghz-and-dual-band-wireless-mcus-and-modulesTue, 08 Sep 2026 10:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b2abdb97-7e70-45f7-b4b1-18f8a0b3da8dTirthal PatelPart Number: CC1312R We are currently evaluating wireless connectivity solutions for an upcoming low-power wireless device and are looking for suitable Wireless MCUs and ready-to-use wireless modules from Murata. We are primarily looking for: 1. Sub-GHz Wireless MCUs &amp; Modules Support for the 868 MHz band Low power consumption Long-range communication Suitable for IoT applications 2. Dual-Band Wireless MCUs &amp; Modules Support for 868 MHz Sub-GHz Additional support for 2.4 GHz Low power consumption Compact size Long-range communication Suitable for IoT applications Could you please recommend suitable products from your current portfolio and provide the following information? Complete part number Datasheet/product information Package/module dimensions and antenna options Development kit availability Product lifecycle and minimum 5-year availability/EOL support MOQ and lead time Unit pricing at 10K and 100K quantities We would appreciate your recommendations for suitable Sub-GHz and dual-band Wireless MCUs and modules , along with the above technical and commercial information. Thank you, and we look forward to your response. Best regards, Tirthal Patel Senior Hardware EngineerCC1312Rhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1677838/cc1352p7-cc1352p7-sub-1g-proprietary-866-mhz-zigbee-2-4g-coordinator-in-one-binary-using-dmmsch-is-a-combined-rf-patch-available/6475812Tue, 08 Sep 2026 09:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2a67e650-196f-4abf-946e-d4d9bbeaf548nitish kareliyaHi Arthur Can you please guide us on this as our POC is getting delayed ? Regards, Nitishhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679898/cc1312r7-sensor-controller-init/6475439Tue, 08 Sep 2026 04:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6fbb9c8c-d5df-4831-85c1-c6898a06b689SiriHi As far as I know, there should not be any changes as to how things are done on the CC1312R7 compared to on the CC1312R1. Can you please provide us with a simple demo code (complete project or a description to the changes we need to do to one of our SDK examples) to trigger this behavior so that we can reproduce the issue here and debug it? I assume that you have started from scratch using one of the examples in the SDK for the CC1312R7 when you have done the porting from CC1312R1, and not have tried to just do changes to your CC1312R1 project to make it run on the CC1312R7? BR Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1676455/cc1352r-dmm-support-in-rtls-responder/6474950Mon, 07 Sep 2026 11:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9d784640-0d34-4051-a657-a6f84a5ceab6RSSATHEESH KUMARHi, We have not used Channel Sounding in our application. We are currently using AOA only. For debugging purposes, we tested the Tag with the basic BLE. When we disable USE_PERIODIC_ADV and RTLS_CTE, the Tag successfully transmits regular basic BLE advertisements. Please refer to the attached screenshot showing the current test results. Thanks,https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679898/cc1312r7-sensor-controller-initMon, 07 Sep 2026 09:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:00be4e40-6f2e-46f7-a72a-3fbcbff47639Shlomo RabinovitchPart Number: CC1312R7 in our previous projects based cc1312r1 we used the init of sensor controller as a simple scifInit() in any case of start, Power on/ ext reset/ debug reset and so on. no in the new project based cc1312r7 we used a same module, but in case of debug reset or probably WD too, it stuck in the initialization. I put the following code in order to ovewrcome it, but i do not like the need to go inside and deal with the registers. the question is: &quot;whyit doesn&#39;t work as it was in the past?&quot; I though that the architecture is a same and the same solution was expected to continue working ThanksCC1312R7https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679695/cc1352p-when-will-cc1352p-and-related-sdk-support-subghz-zigbee-suzi/6474627Mon, 07 Sep 2026 06:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d8e43879-dffb-4013-b22a-b1ab183448eaSiriThere are no current plans for Su-Zi. BR Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679455/cc1314r10-cc1314r10-2nd-cmd_prop_tx_adv-long-preamble-after-boot-never-leaves-status-idle-unless-spaced-seconds-apart/6474475Mon, 07 Sep 2026 04:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3a05b6de-ca18-45d0-901f-f59bf7577077Harsiddh PatelSubject : CC1314R10 — CMD_PROP_TX_ADV stuck ACTIVE after CMD_PROP_RX_SNIFF on a shared RF handle Setup : two CC1314R10 nodes, a battery sensor (WoR: CMD_PROP_RX_SNIFF + long-preamble CMD_PROP_TX_ADV) and a mains hub (receives, then sends an encrypted reply with a long-preamble TX_ADV so the duty-cycled sensor hears it). Same PHY/RF_cmdPropRadioDivSetup on both. SDK simplelink_cc13xx_cc26xx 8.32. Symptom : the hub&#39;s reply TX_ADV intermittently sticks at status = 0x0002 (ACTIVE) and never completes — RF_runCmd never returns; the task pends forever. The first reply after a fresh RF_open always succeeds; a later reply — one that follows a CMD_PROP_RX_SNIFF on the same handle — is the one that hangs. Intermittent per boot (one boot ran 25–35 replies clean; most wedge on the 1st–2nd). Checked your suggestions: bFsOff = 0 on both the RX and TX commands (SysConfig). TX_ADV startConf is zero-initialized. Instrumented the reply as RF_postCmd(CMD_FS → CMD_PROP_TX_ADV chain) + poll: at the hang, CMD_FS.status = 0x0400 (DONE) but CMD_PROP_TX_ADV.status = 0x0002 (ACTIVE) for 1.5 s. So the synth is tuned; the TX_ADV starts but never finishes. Set TX_ADV preTime = 0 (no extended preamble) — still hangs identically, so it&#39;s not the RAT preamble trigger. RF_flushCmd/RF_cancelCmd on the stuck command also block — the rfcore is unrecoverable in SW once this happens. Board-swap: flashed the hub firmware onto the other (known-good) board — wedges identically, so it&#39;s firmware, not a bad board. What differs between the working sensor and the wedging hub: the sensor does RF_close/RF_open per TX (and allows STANDBY between sniffs, so the rfcore fully power-cycles); the hub is mains and can&#39;t standby (keeps its console UART), so it keeps one handle and/or does close → settle(IDLE-PD drop) → open. Making the hub power-cycle the RFC domain between the sniff and the reply TX helps (25 replies vs 2) but isn&#39;t deterministic — a longer settle was actually worse, confirming it rides an intermittent condition. Questions : Is CMD_PROP_TX_ADV ↔ CMD_PROP_RX_SNIFF on a single RF handle a known-unsupported/wedging combination? What&#39;s the recommended teardown/sequence to go from a sniff to a long-preamble reply TX (and back) — is your RX_ADV → TX_ADV_Ack rfcore-chained pattern the right approach even when the reply payload is computed after RX (i.e. can&#39;t be pre-staged, only the ~180 &#181;s chain window)? Any RF driver call that reliably resyncs the RAT / resets the rfcore between the two commands without a full RF_close/RF_open?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1677838/cc1352p7-cc1352p7-sub-1g-proprietary-866-mhz-zigbee-2-4g-coordinator-in-one-binary-using-dmmsch-is-a-combined-rf-patch-available/6474316Sun, 06 Sep 2026 16:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:761109e1-f5f0-4295-9fc8-60d55010c64cnitish kareliyaHi Arthur, I tried with the changes as suggested above in Zigbee + BLE example for Sub-1G. Is activityInfo = 0x07D0 (DMM_BLE_CONNECTION) the correct value for a Sub-1G sniff submitted through the BlePeripheral slot? Or should a different activity type be used? Can you please suggest what can be done to make this work with Sub-1 + zigbee? Regards, Nitishhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679695/cc1352p-when-will-cc1352p-and-related-sdk-support-subghz-zigbee-suziSun, 06 Sep 2026 03:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:dfd8ece4-5991-4e35-8d7c-0134b68c428cYiKai ChenPart Number: CC1352P As title!CC1352Phttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1679686/cc1350-cc1350-launchpad-rev-1-2-schematic-and-bomSat, 05 Sep 2026 17:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5fc7fceb-8d70-4cf5-9615-12b17c0c47eaMichael CressPart Number: CC1350 Hello: I need the schematic and BOM for the Rev 1.2 launchpad boards (US). It seems that only the 1.3 version&#39;s info is published. I have to have this to fix my boards after my hot air gun blew the RF capacitor off the board.CC1350Wireless Infrastructurehttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1677838/cc1352p7-cc1352p7-sub-1g-proprietary-866-mhz-zigbee-2-4g-coordinator-in-one-binary-using-dmmsch-is-a-combined-rf-patch-available/6473819Fri, 04 Sep 2026 15:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:286f5599-c949-4ef7-ba3a-bbda702b2caenitish kareliyaHi Arthur, Thanks for the suggestion. I will update the code as you suggested and update on the test result. Regards, Nitish