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/1681196/cc430f5135-sub-1ghz-migration-from-cc430-worldwide-bands-narrowband-fsk-tx-10dbm-15ma-with-legacy-simple-spi-command-control-no-network-processor/6496938Tue, 29 Sep 2026 09:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:67107290-1ec2-47d7-b989-c74f7943ee8dRGWFully understand Mike. Closing this thread and we can take this via email.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685323/cc1310-rom-bootloader-not-communicating-via-uart/6496883Tue, 29 Sep 2026 08:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2611ecc9-a2c3-45fc-ad5c-f11714f9ceb4Arthur R☑️Hi JJ, Indeed, you definitely do not need RTS and CTS pins in order to get the bootloader to work. Are you sending the two 0x55 bytes before trying to send the ping commands? [quote userid=&quot;719705&quot; url=&quot;~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685323/cc1310-rom-bootloader-not-communicating-via-uart/6496672&quot;]After I send several bytes in a row it seems to straighten itself out and actually send what I want to send, but by that point the ROM bootloader is probably completely confused[/quote] This would make it look like the device manages to sync its baudrate after some bytes anyway. Do you get better results if you try with 19200 bps (less baudrate missrate) ? Also, is VDDIO being fed 3.3V? How does the waveform look like in an analog capture? Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1681196/cc430f5135-sub-1ghz-migration-from-cc430-worldwide-bands-narrowband-fsk-tx-10dbm-15ma-with-legacy-simple-spi-command-control-no-network-processor/6496791Tue, 29 Sep 2026 06:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec098db3-a168-4cdd-a1bb-af65c742a088Mike Wu1Hi, Yes, and they are one of our key VIP customers for Sub-1GHz in Taiwan. A critical requirement for them is to build their own proprietary RF protocol to maintain backward compatibility with their legacy products. The local Taiwan TI team would like to confirm if there are any feasible migration paths or new solutions available that could enable this customer to adopt TI&#39;s latest products for their next-generation design. Thanks!https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685323/cc1310-rom-bootloader-not-communicating-via-uart/6496672Tue, 29 Sep 2026 04:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:89e380d0-4264-4c21-b35b-545d66e0fa21JJ SmithAttached is the part of the schematic that shows the Holtek bridge and CC1310, so you can see how they are connected. I can turn off the hardware flow control in the Holtek, but it doesn&#39;t seem to affect the issue. I also attached a logic analyzer capture, and I just discovered something. It&#39;s supposed to show 0x55, but you can see it&#39;s showing 0xFD. After I send several bytes in a row it seems to straighten itself out and actually send what I want to send, but by that point the ROM bootloader is probably completely confused. I never noticed this issue because this does not happen when I send bytes to my application. I&#39;ve been using this device for months, and I&#39;ve never had issues with the UART in my application, or the UART in my firmware bootloader. So it seems like the ROM bootloader is interfering with the RX line. Thoughts?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683516/smartrf-studio-7-smart-rf-studio-is-not-giving-correct-value-same-as-protocol-ble-zigbee-of-the-sdk/6495814Mon, 28 Sep 2026 13:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b49f2d2c-9bef-4de0-b042-92f5285d6b71RGWHi, Apologies for late reply. Do you have access to a VNA ? This is the best equipment for measuring the antenna&#39;s resonance and determining if there is antenna detune or not. It is natural for the antenna to have nulls. With multi-path propagation, the nulls can also be around 10 dB so take this into account when measuring just the RSSI.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1681196/cc430f5135-sub-1ghz-migration-from-cc430-worldwide-bands-narrowband-fsk-tx-10dbm-15ma-with-legacy-simple-spi-command-control-no-network-processor/6495763Mon, 28 Sep 2026 12:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4be2d06-fcd0-43b4-99e6-80a97359f8b7RGWHi Mike, Is this the customer with crane control ?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1681196/cc430f5135-sub-1ghz-migration-from-cc430-worldwide-bands-narrowband-fsk-tx-10dbm-15ma-with-legacy-simple-spi-command-control-no-network-processor/6495761Mon, 28 Sep 2026 11:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:63ef41cd-d9e0-43be-8034-c4764d40b9aaRGWHi Mike, Is CC1125 and an external DCDC converter an option here ? CC1125 is a natural upgrade from CC1101 and a huge RF performance upgrade whilst keeping a similar command/strobe control interface. CC1125 has approx. 38 mA for 3.0 V at 10 dBm Tx so you will need an external DCDC converter here to reduce the current consumption. Otherwise, it is CC13xx but without the legacy strobe control.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685323/cc1310-rom-bootloader-not-communicating-via-uart/6495548Mon, 28 Sep 2026 07:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:daa08deb-793d-4402-a26f-078f27430ebeArthur R☑️Hi JJ, Do you have a logic/oscilloscope captures of the ping sequence? Also, a schematic snippet could help us a lot. Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685323/cc1310-rom-bootloader-not-communicating-via-uartFri, 25 Sep 2026 22:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:428961f5-7efe-4af2-b79c-06000daf6e8fJJ SmithPart Number: CC1310 We have designed a custom PCB based around the CC1310. We use a Holtek USB-UART bridge that we would like to use for loading with the ROM bootloader. We also use SPI as a backup, and bootloading via SPI works as expected. We can communicate with our application firmware via UART through the Holtek chip. Unfortunately, the ROM bootloader does not work. If I repeatedly send pings maybe 1 out of 10 or so gets a response, so I know I have the correct pins, and it is almost working. My guess is the auto baud rate doesn&#39;t like the Holtek device for some reason. I have tried various baud rates, but they all act the same. Does anyone have any idea how I might get the bootloader working via UART with the Holtek bridge?CC1310Wireless Infrastructurehttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685164/sensor-controller-studio-scif_osal_tidpl-c---osalwaitonctrlready-appears-to-invert-semaphorep_pend-return-value-check/6494469Fri, 25 Sep 2026 07:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b880e897-80e7-4b4b-8ce4-5476a73a973bArthur R☑️Hi Amrit, Good catch, I will report the bug. I think it has been caused by an incorrect migration of the old TIRTOS code, where SemaphoreP_pend was indeed returning true if successful: If you select TI-RTOS as the operating system in your project configuration, you can actually inspect the generated tirtos OSAL code: Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1685164/sensor-controller-studio-scif_osal_tidpl-c---osalwaitonctrlready-appears-to-invert-semaphorep_pend-return-value-checkFri, 25 Sep 2026 04:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:90bb06ce-3091-491b-9612-75a9319418fbAmrit Pal SinghPart Number: SENSOR-CONTROLLER-STUDIO Hi, I&#39;m working with the Sensor Controller Interface (SCIF) driver generated by Sensor Controller Studio for the TI Driver Porting Layer (DPL) OSAL, running on embOS (CC1314). I believe I&#39;ve found a logic bug in the generated scif_osal_tidpl.c file, specifically in osalWaitOnCtrlReady(). The relevant code: if (SemaphoreP_pend(semCtrlReadyHandle, timeoutUs / ClockP_getSystemTickPeriod())) { osalWaitOnNblLocked = false; result = SCIF_SUCCESS; } else { osalWaitOnNblLocked = false; result = SCIF_NOT_READY; } This treats a truthy return from SemaphoreP_pend() as success. However, per the DPL&#39;s documented SemaphoreP_Status enum, SemaphoreP_pend() returns a status code where SemaphoreP_OK == 0 (success), SemaphoreP_TIMEOUT, and SemaphoreP_FAILED. Since SemaphoreP_OK is 0 (falsy in C), a successful pend takes the else branch here and is incorrectly reported as SCIF_NOT_READY. On my embOS DPL port, SemaphoreP_pend() correctly returns SemaphoreP_OK (0) on success, following the documented convention - which means this code always reports SCIF_NOT_READY even when the semaphore was genuinely obtained within the timeout. I also found a related symptom reported on FreeRTOS in this thread: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1477271/lp-em-cc1354p10-sensor-controller-freertos-and-semaphore-timeout - scifWaitOnNbl() always returning SCIF_NOT_READY and ignoring the specified timeout, even though tracing showed the underlying task completing its work correctly. That thread&#39;s diagnosis leaned toward a race condition, but given what I&#39;m seeing on embOS, I suspect the same root cause may apply there too, since FreeRTOS&#39;s DPL port likely also returns the standard SemaphoreP_Status enum with SemaphoreP_OK == 0. Could someone confirm whether this is a known issue, and whether it&#39;s been fixed in a newer version of Sensor Controller Studio? If not, I&#39;d like to flag it as a defect. The straightforward fix would be to compare explicitly against SemaphoreP_OK rather than relying on truthiness: if (SemaphoreP_pend(semCtrlReadyHandle, timeoutUs / ClockP_getSystemTickPeriod()) == SemaphoreP_OK) { ... } Happy to provide more details (SCS version, exact SDK version, target device) if useful for reproducing this. Thanks, AmritSENSOR-CONTROLLER-STUDIOhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683708/cc1312r-what-are-the-recommended-parameters-of-the-rf-matching-circuit-for-cc1312r1-when-the-rf-works-at-1-2-ghz/6492772Wed, 23 Sep 2026 18:31:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c2ae92ea-0ed5-484c-a0fc-bc3ca871516aRizwan MurjiThese are mandatory Thanks, Rizhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1674594/cc2745r10-cs-evm-doc-cert-lp-em-cc2745r10-q1-requesting-altium-design-file/6492771Wed, 23 Sep 2026 18:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:baeeeb29-1bbf-49dc-a82a-39c098ca40e0Rizwan MurjiHi Sankaran, Unfortunately we do not have Altium available for this. It is only in Cadence format. Thanks, Rizhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683708/cc1312r-what-are-the-recommended-parameters-of-the-rf-matching-circuit-for-cc1312r1-when-the-rf-works-at-1-2-ghz/6491998Wed, 23 Sep 2026 05:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5c248629-fb17-47c6-8b85-16f09cdbe58azili flAre L11, L21 and C11 mandatory or optional?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683708/cc1312r-what-are-the-recommended-parameters-of-the-rf-matching-circuit-for-cc1312r1-when-the-rf-works-at-1-2-ghz/6490920Tue, 22 Sep 2026 11:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:45d9ecae-c699-4262-9e74-44f0345ace83RGWHi, We do not officially have the component values for the CC1312R at 1200 MHz but refer to the https://www.ti.com/lit/zip/SWRC371 as a base for 863-928 MHz operation. Then update the BOM/schematic to the following values for 1200 MHz operation: The I2S interface pins, MCLK pin and SPI pins of CC1312R can be arbitrarily mapped to any DIO.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683574/cc1310-cc1310---attach-debugger---ccs-20-4-1-4__1-10-1/6490647Tue, 22 Sep 2026 07:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a457db4b-4740-4223-bdf3-6b5950f7b4baAchim Kraus&gt; Is this a modified application? Yes, it&#39;s a custom application. In the meantime I also found the root cause, which was not a different initialisation for PIN and Power ON, Watchdog or System resets, which I assumed. It was pretty simple a buffer overflow, when something slightly longer than &quot;PIN&quot; was sprintf() in the diagnose message (printing &quot;PIN&quot; works, printing &quot;Power ON&quot; overflows .... One thing I found, which I wasn&#39;t aware is, that the RAM variables seems to be sorted somehow. So the a &quot;old trick&quot; char pad0[10]; char buf[100]; char pad1[10]; needs to be checked in the symbol map, because they may have been placed somewhere else. Therefore the &quot;Power ON&quot; print overflows into rxBuffer and not my &quot;honey pads&quot;. rxBuffer contains the setup of the receiver queue, so it unintended changed the pNextEntry, which then causes the malfunction. Fixed. Stable again.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1644025/cc1310-how-can-i-correctly-generate-my-hex-file/6489455Mon, 21 Sep 2026 11:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9ed68065-b1c5-4514-98a0-af8a305eb383Arthur R☑️Also, if it an actual issue with the image being generated, here is probably what you are looking for: CCS/CC1310: Hex file generated using ARM Hex Utility is not working - 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/1683574/cc1310-cc1310---attach-debugger---ccs-20-4-1-4__1-10-1/6489398Mon, 21 Sep 2026 10:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0a0ab70a-a313-421d-8f4b-b78e65018ea4Daniel Guarecuco AguiarHi Achim, Is this a modified application? The default rfPacketTx.c doesn&#39;t have that many lines (1721+). Could you share you .c file or share more information about the issue? What are you trying to do? Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683708/cc1312r-what-are-the-recommended-parameters-of-the-rf-matching-circuit-for-cc1312r1-when-the-rf-works-at-1-2-ghzSun, 20 Sep 2026 02:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3dbda244-ea64-492d-91f9-2b3452060f68zili flPart Number: CC1312R What are the recommended parameters of the RF matching circuit for CC1312R1 when the RF works at 1.2 GHz, including the recommended values of inductors and capacitors? Also, can the I2S interface pins and MCLK pin and SPI pins of CC1312R be arbitrarily mapped to all DIO1~DIO30 pins?CC1312Rhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1683574/cc1310-cc1310---attach-debugger---ccs-20-4-1-4__1-10-1/6488427Fri, 18 Sep 2026 16:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8ebd47a3-4e5b-4e5f-91eb-c1451656b9b7Achim KrausHm, if it stops in the application the callstack looks like: mainThread() 0x0000181E rfPacketTx.c 1721:7 _pthread_runStub() 0x0000C74C pthread.c 725:5 0x1001B424