https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1662635/cc2745r10-q1-after-calling-gattservapp_processcharcfg-without-exchanging-mtu-it-will-run-to-hardfault-in-basic-ble-project/6413912Mon, 13 Jul 2026 13:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3641d5c1-25db-4ad8-8f69-edc95c31ad81Kevin QiuConnor, Yes, I file a bug, we will fix it in the next sdk Regards, Kevinhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1663673/cc2640-debug-cannot-startMon, 13 Jul 2026 12:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2dc78e62-64b8-4928-82a8-9d97637fd3c5luigi DesideratoPart Number: CC2640 On a custom board populated with CC2642 I have to debug it through Launchpad emulator XDS110. 1st of all I imported &quot;project_zero&quot; app. There are two cases arising: 1) compiling original code, no errors arise but it is impossible to debug it because of a different target. This is the diagnostic: Cortex_M3_0: GEL Output: Memory Map Initialization Complete. Cortex_M3_0: Device revision &#39;0x4&#39; unknown for selected target. Assuming latest known revision: Rev. 2.4. Cortex_M3_0: GEL Output: Board Reset Complete. Cortex_M3_0: Command=20 -- addr=0x00002000 -- length=0x00001000 Cortex_M3_0: File Loader: Memory write failed: Status 0x0102: Target flashloader failed to erase sector 1. Low level function returned status 3 (Incorrect parameter value). Cortex_M3_0: GEL: File: H:\Move\Software\ble5_project_zero_cc2640r2lp_app\FlashROM_StackLibrary\ble5_project_zero_cc2640r2lp_app.out: Load failed. Note no linker cmmand file is available in the same tab 2) if in the property CCS general tab I change the target processor to CC2642R1F, the compilation ends with the following diagnostic: &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 254: error #10263: FLASH memory range has already been specified &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 254: error #10264: FLASH memory range overlaps existing memory range FLASH &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 257: error #10264: FLASH_LAST_PAGE memory range overlaps existing memory range FLASH &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 260: error #10263: SRAM memory range has already been specified &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 260: error #10264: SRAM memory range overlaps existing memory range SRAM &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 206: warning #10190-D: absolute symbol &quot;__STACK_TOP&quot; being redefined &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 206: warning #10190-D: absolute symbol &quot;__STACK_TOP&quot; being redefined &quot;C:/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/ble5stack/common/cc26xx/ccs/cc26xx_app.cmd&quot;, line 206: warning #10190-D: absolute symbol &quot;__STACK_TOP&quot; being redefined error #10010: errors encountered during linking; &quot;ble5_project_zero_cc2640r2lp_app.out&quot; not built &gt;&gt; Compilation failure makefile:187: recipe for target &#39;ble5_project_zero_cc2640r2lp_app.out&#39; failed gmake[1]: *** [ble5_project_zero_cc2640r2lp_app.out] Error 1 makefile:180: recipe for target &#39;all&#39; failed gmake: *** [all] Error 2 * Build Finished * So I cannot debug either. Note the linker file in this second case is changed to cc26x2r1f.cmd Any idea? Thanks LuigiCC2640Wearables (non-medical)https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1663636/cc2744r7-q1-the-random-number-generation-sequence-in-the-ti-osal-layerMon, 13 Jul 2026 11:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a2138120-7336-41e4-ab92-779310ff3c2aKai KimPart Number: CC2744R7-Q1 Other Parts Discussed in Thread: SYSCONFIG Hi Team, Currently, the application uses the following API (osal_rand) to generate random numbers. Could you please confirm the random number generation sequence of this API? Specifically, please clarify whether it uses a TRNG + DRBG combination or generates random numbers using TRNG alone , etc. (it is required to use TRNG + DRBG) For reference, TRNG is enabled in the ti_driver section of SysConfig . (DRBG does not have a separate configuration option, so it was not configured.) Best Regards, Kai KimCC2744R7-Q1SYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1663416/cc2745r10-q1-question-in-hsmxxf3-c-on-hsmxxf3_isstandalonedmasupportenabled-with-hsm-version-3-4-5Mon, 13 Jul 2026 02:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b139c907-e7d1-4b62-9fde-ddadb83db904ConnorPart Number: CC2745R10-Q1 Hi team, I found something strange that, with HSM FW 3.4.5, HSMXXF3_isStandaloneDMASupportEnabled will not return true, causing ECDHXXF3HSM_initializeHSMOperations() will not release the CommonResourceXXF3_accessSemaphore. Could the team check the possibility of my notice? Thanks! Best Regards, ConnorBody Electronics &amp; LightingCC2745R10-Q1https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1662635/cc2745r10-q1-after-calling-gattservapp_processcharcfg-without-exchanging-mtu-it-will-run-to-hardfault-in-basic-ble-project/6413229Mon, 13 Jul 2026 02:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2ce7b4d0-21bd-4c64-8ec4-c7a48741320aConnorHi Kevin, Thank you so much for your reply. From my understanding, it should return an Error code rather than entering hard fault/getting memory corruption. Will we fix it in the next SDK? Best Regards. Connor.https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1662635/cc2745r10-q1-after-calling-gattservapp_processcharcfg-without-exchanging-mtu-it-will-run-to-hardfault-in-basic-ble-project/6413134Sun, 12 Jul 2026 15:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6375bdca-6c8f-4554-ad0c-d5d47d481684Kevin QiuHi Connor, In current BLE stack implementation, it must exchange MTU size before sending greater than (ATT_MTU - 3) Bytes data. The BLE stack will allocate a (ATT_MTU - 3) bytes buffer when calling GATTServApp_ProcessCharCfg(). When you send more than (ATT_MTU - 3) bytes, the data will not be sent due to mismatching ATT_MTU size. But it still allocates (ATT_MTU - 3) Bytes from heap, then free the length from SimpleGattProfile_readAttrCB. It caused memory corruption. Regards, Kevinhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1661214/cc2642r-oob-secure-connections-dh-key-check-failed-1-way-oob-privacy/6412674Fri, 10 Jul 2026 17:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:024778a6-1c74-4d88-a486-d0aed39388b3Josh AldersonHi Marco, There is a key mismatch when the DH key check is happening. This might be happening due to NXP using the identity address from the NFC instead of TI&#39;s RPA. The central will use the RPA it used when pairing in the calculation for the DH key check. The exact information I need is not displayed in the ellisys log so I can&#39;t look at the exact values to verify. Check what address the NXP device is using when doing the f6 part of DH key checks and see if it matches the RPA address of the TI device used when pairing. These sections of the 6.2 bluetooth spec provide more information on what is used in the computation for DH key checks. Vol 3, Part H, Section 2.2.8 and Vol 3, Part H, Section 3.5.7 Best, Joshhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1656365/cc2340r5-add-drive-strength-control-to-zephyr-gpio-driver/6412532Fri, 10 Jul 2026 15:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:38c2a93a-160f-4f1f-856d-7aaf99f3653eGing GonzalezMunan, I have verified that the patch (linked below) you provided works on 9.14. And I have created the ticket to resolve this issue. Thanks! e2e.ti.com/.../0001_2D00_Add_2D00_drive_2D00_strength_2D00_control_2D00_for_2D00_CC23x0.patch Regards, Ginghttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1663201/cc2642r-load-capacitance-hse-48mhz-crystal--performance-issues/6412337Fri, 10 Jul 2026 12:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:beb0c858-ffab-4ab9-a033-fdc279d09fa9Ryan Brown1Hi Jan You can disable the XOSC Cap Array Modification in SysConfig -&gt; Device Configuration, or enable and determine the cap array delta value, and there are more instructions for tuning the HF oscillator in Section 6.4 of SWRA640 . I would not recommend adding a frequency offset to the BLE channel at the moment, instead let&#39;s focus on addressing the root cause. You can use the OSC_AdjustXoscHfCapArray Driverlib API to adjust the CCFG value at runtime Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1663217/cc2745r7-q1-guidance-required-for-migrating-project-from-cc2745r10-to-cc2745r7Fri, 10 Jul 2026 12:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:196e0760-2c97-41cf-837f-5e68e4c55cb7Ratan DaleiPart Number: CC2745R7-Q1 Other Parts Discussed in Thread: SYSCONFIG Hello TI Team, We have developed our custom board using the CC2745R7 device. Previously, we were using the CC2745R10 LaunchPad for development, and all of our existing software is configured for the CC2745R10. Could you please guide us on how to migrate the project from CC2745R10 to CC2745R7? Specifically, we would like to know: Where do we need to change the target device from CC2745R10 to CC2745R7? Are there any project settings, SysConfig changes, or configuration files that need to be updated? Are there any additional steps or considerations required during the migration? Please suggest the recommended approach for this migration. Thanks &amp; Regards Ratan.Software-defined vehicleSYSCONFIGCC2745R7-Q1https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1658797/cc2340r5-device-rom-bootloader-backdoor-pin-handling-in-case-of-power-failure/6412320Fri, 10 Jul 2026 12:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7aac0b67-0370-4b0f-970d-08469ba66d50Ryan Brown1You will get an error return status from the ROM bootloader if you attempt to perform a download without first performing a mass erase. Regards, Ryanhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1663201/cc2642r-load-capacitance-hse-48mhz-crystal--performance-issuesFri, 10 Jul 2026 11:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:185e3ffc-f00c-4c1e-92f6-81a92d9b6f04Jan BockPart Number: CC2642R Other Parts Discussed in Thread: SYSCONFIG We have been experiencing a strange issue with the BLE performance and are therefore looking for solutions. We think we might have a HW solution, but we are also looking for a SW solution for the devices in the field. The issue is related to the loading capacitance on the HSE 48MHz crystal. We see that the loading capacitance adds a frequency shift to the set channel and frequency. We suspect that the internal capacitance is enabled and is therefore increasing the capacitance that is causing the drift. We have tried to modify that value a bit, and have seen a positive impact. MODE_CONF is the register we modify to set the cap array tuning to a negative value (signed 8-bit) Questions; Whats the lowest acceptable value that we can set? How can we disable it completely? Is there a way to add a frequency offset to the BLE channel? Could you modify the CCFG value over UART on the fly? Perhaps not.Infotainment &amp; ClusterCC2642RSYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1658299/cc2340r5-zephyr-peripheral-sample-not-connecting-to-simplelink-connect-app-ios/6412079Fri, 10 Jul 2026 07:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a3fd4eb0-cf79-4b5c-8c41-91babf7391dfLeaHi Munan ! I got word that the following errors are a known issue for now, and that they should not cause any functional errors, it&#39;s only cosmetic. It happens upon the initialization of the BLE stack, and when pairing. [00:00:08.916,843] bt_ctlr_hci_driver: Failed to send buffer to device [00:00:08.916,862] bt_hci_core: send_cmd: Unable to send 0x2025 to driver (err -2) [00:00:08.916,885] bt_hci_core: No command sent for cmd complete 0x2025 For the iPhone issue, I haven&#39;t been able to reproduce it on the iPhones that we have at the office, though they are a little bit old. Do you have a BLE Sniffer that you could use to have logs of the error ? Kind regards, Leahttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1658797/cc2340r5-device-rom-bootloader-backdoor-pin-handling-in-case-of-power-failure/6411927Fri, 10 Jul 2026 05:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c682f053-959c-4810-8753-70c75b9e9b09Rushikesh AidaleHello Ryan, Thanks for your valuable feedback. I guess there is no other option left for me other than to implement a secondary bootloader. Just in case, what if I do ROM bootloader firmware flashing sequence without using chip erase and start flashing the firmware directly from a desired location? I mean, would this be allowed from ROM bootloader?https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1660671/cc2745r10-q1-inconsistent-cs-results-between-car-node-and-key-node/6411566Thu, 09 Jul 2026 21:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f1b5f64d-9238-4d04-9024-636c6fa14fefEshaan TibrewalaHello Shreeya, Yes if you are using an external antenna connected to the SMA pin, then CA2 antenna needs to be reoriented to the CA1 pads so that external antenna can be utilized. By booster antenna, are you referring to the one on the launchpad? Can you please send a picture of the logs you are seeing? Thankshttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1661821/cc2745r10-q1-keystore---what-is-the-recommended-way-to-preserve-and-reuse-persistent-hsm-asset-store-keys-across-ccs-programming-cycles/6411294Thu, 09 Jul 2026 16:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:57b136b0-8598-4bf7-945c-8f121bb1a6e9Blake SandersHello Marcus- Apologies for the delayed response. Thanks for the detailed report; I am looking into your issue now. I have a few clarification questions that would help me narrow down the root cause: 1. What sdk version is your customer using? 2. Are you calling HSMXXF3_provisionHUK() after psa_crypto_init() on every boot? The HUK lives in OTP and survives reprogramming, but it must be re-activated in the HSM each reset before any wrapped keyblob can be unwrapped from Flash. 3. What is the full sequence of PSA/HSM calls you make at startup before attempting to use the persistent key? For example: psa_crypto_init(); HSMXXF3_provisionHUK(); // anything else? 4. When you detect the failure and recreate the key, does it succeed reliably on the first attempt? (This would confirm the HSM itself is healthy after reset.) 5. Does this also happen after a plain power cycle with no reprogramming — i.e., does the persistent key work correctly across a simple reset? Best, Blakehttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1661631/lp-em-cc2340r5-nesb-protocol/6411248Thu, 09 Jul 2026 16:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5eb0e0a9-6ff9-459a-bcd7-5810f9456b27Alex FagerHello Danilo, Thank you for the update! I do want to let you know that BMACK exists (Bare-metal ACK) is a more generic ACK PHY that customers can develop with instead of NESB but if you need compatibility specifically with NESB then you cannot use BMACK. You can control the payload info in ACK in BMACKs. (You can generate a BMACK PHY with your SDK&#39;s Sysconfig its one of the custom options) Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1661472/cc2745r10-q1-facing-issue-in-shutdown-and-wakeup-based-on-ais2dw12-interrupt/6411204Thu, 09 Jul 2026 15:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c5936149-6cda-4d88-9f0b-39c6e104937fBlake SandersHello- Glad that the device is successfully entering shutdown. On the CC2745R10-Q1 you should be seeing ~165nA shutdown current. It is likely that the motion sensor (or another peripheral if connected) is drawing that additional current when in shutdown. I would recommend physically disconnecting this peripheral and any others and remeasuring the current. I also believe that it is required to put this sensor into a shutdown state itself before calling SPI_close(). I would look at the manufacturer&#39;s datasheet and follow their instructions for how to put the sensor into shutdown or a low-power mode. If you need further help on this topic, please open a new thread so that we can keep each issue separate. We would be happy to help you on there. Thank you, Blakehttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1661472/cc2745r10-q1-facing-issue-in-shutdown-and-wakeup-based-on-ais2dw12-interrupt/6411034Thu, 09 Jul 2026 14:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e6ea31ef-2aab-4e39-9e6f-eec92d573c39Balaji WankhedeHello Sanders, Thanks you for your response. My issue resolved. But I have one more concern still i&#39;m getting more shutdown current near by 195uA current. but in this device i&#39;m using AIS2DW12 motion sensor based on the SPI communication. before Enter into the Shutdown. if (controllerSpi != NULL ) { SPI_close (controllerSpi); controllerSpi = NULL ; } GPIO_setConfig (Mot_Det, GPIO_CFG_IN_PU | GPIO_CFG_SHUTDOWN_WAKE_LOW); /*Device Enter into the shutdowm mode*/ Power_shutdown ( 0 , 0 ); please let me know is it correct or not. Thanks &amp; regards Balaji Wankhedehttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1661214/cc2642r-oob-secure-connections-dh-key-check-failed-1-way-oob-privacy/6410753Thu, 09 Jul 2026 10:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:306e86e8-a66e-4fa2-8ceb-f7d1c6143413Marco MagdyHello Josh, I disabled debug keys on the Central so both devices are forced to use real keypairs. However, the pairing is still failing with a DH Key Check Failed at the exact same spot. I have attached the updated Ellisys trace. As you will see, both sides are now successfully exchanging Regular Public Keys , but the math is still breaking during Authentication Stage 2. To give you the exact context, we have shifted to a 1-Way NFC + ATT OOB architecture: NFC Exchange: The Central (TI) sends its Identity Address and IRK to the Peripheral via NFC. The Central does not receive the Peripheral&#39;s data in return. Connection: The Peripheral starts Directed Advertising . Controller Privacy is ENABLED on the TI device ( ADDRMODE_RP_WITH_RANDOM_ID ), so it connects using a temporary RPA. ATT Exchange: After connection, the TI device sends its local OOB Confirm and Random values to the NXP device over the BLE link via an ATT Write Command. Pairing: SMP Secure Connections pairing initiates. Best Regards e2e.ti.com/.../dhkey_5F00_check_5F00_failed_5F00_issue_5F00_regular_5F00_key.zip