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/1692251/cc2642r-q1-insufficient-negative-resistance-of-the-oscillation/6529854Wed, 04 Nov 2026 07:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:39460471-eff8-48cd-b606-c6d3109cb867xuanfeng fuHi Cashmere, How to adjust the internal capacitor array? We tried to adjust it, but we are not sure if it has taken effect.https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1695128/cc2745r10-q1-clarification-required-ble-passkey-entry-pairing-and-passkey-update-flowWed, 04 Nov 2026 04:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:36e08e41-2ab6-4c9a-9df3-af135048c413Amit DPart Number: CC2745R10-Q1 Hi, How can we implement the complete BLE Passkey Entry pairing flow between the Android APK and the TI CC2745R10 LCM BLE module? Our requirement is to allow the Android APK to enter a six-digit passkey to authenticate the BLE peripheral using MITM protection and LE Secure Connections, and establish bonding. Could you please clarify the following points? 1. What is the correct I/O capability configuration for our use case, considering that the LCM BLE module does not have a display or keyboard? 2. How should passkey generation and handling be implemented using the GAP Bond Manager callbacks? 3. How can the Android APK initiate pairing and handle six-digit passkey entry? 4. What is the recommended approach for dynamically changing or updating the passkey? I noticed that the `Pairing_passcodeHandler` callback appears to use a statically configured passkey. If we need to change or update the passkey dynamically, what is the recommended implementation flow? Is there any provision to update the passkey at runtime? I have already reviewed the TI BLE Passkey Entry implementation guide: https://dev.ti.com/tirex/explore/node?isTheia=false&amp;node=A__AZlepia.Y63S3T6v-0IjMA__SIMPLELINK-ACADEMY-CC23XX__gsUPh5j__LATEST However, I would appreciate your guidance on the above points, preferably with a practical implementation example for the CC2745R10 using SimpleLink F3 SDK. Regards, Amit DhembreInfotainment &amp; ClusterCC2745R10-Q1https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694597/cc2650moda-cc2650-ble-stack-2-02-08-12-fragmented-notifications-mixed-between-two-connections/6529051Tue, 03 Nov 2026 16:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:54c7d776-9b50-46a0-941f-3ad86ce447f7Faizan HabibHi Thorsten, Thank you for the detailed explanation. I will look into this and get back to you. Best Regards, Faizanhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694570/cc2745r10-q1-is-dynamic-switching-between-the-dc-dc-regulator-and-gldo-supported-in-cc2745/6528993Tue, 03 Nov 2026 15:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bac524e7-3ba8-4e91-9482-ea642a4351b1Chao LIUHello Arthur From a technical point view, is it possible to select DCDC in the bootloader and select LDO in Application ? Will the LDO take effect in application? Thanks .https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694570/cc2745r10-q1-is-dynamic-switching-between-the-dc-dc-regulator-and-gldo-supported-in-cc2745/6528984Tue, 03 Nov 2026 15:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:03fd3255-e7c9-4cee-98cd-b04ea940810cArthur LaurentHi Chao, hi Francois, Francois, thank you for the details. We think that it is valid to keep the DCDC components when operating in GLDO mode.We recommend to remove the inductor in table 6-2 in order to reduce cost and space. What should be considered is that the device will consume more current, as GLDO is less efficient than DCDC. Let me know if you need any further assistance. Best regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694597/cc2650moda-cc2650-ble-stack-2-02-08-12-fragmented-notifications-mixed-between-two-connections/6528824Tue, 03 Nov 2026 13:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9b5855a6-f8eb-4afc-bb02-1edae62cfb14Thorsten OttHi Faizan, thank you very much for your fast reply! We have set MAX_PDU_SIZE to 162 bytes because all our messages will fit in that size. The described problem happened also with shorter data. Increasing MAX_PDU_SIZE to 255 would increase the local buffer/MTU limit, but would not, by itself, increase the negotiated Link Layer data payload size. Therefore, we would not expect this change alone to resolve the observed problem. (see below) With MAX_PDU_SIZE set to 27 bytes the problem is only shadowed but would not fix the underlying defect. It would also limit notification values to 20 bytes. To transport our existing application level telegrams, we would then need to implement application-level fragmentation and reassembly on all devices which normally should be done by the BLE stack. As far as I have understood, MAX_PDU_SIZE defines the size of the data buffer of the L2CAP PDU. But the link layer data payload in Bluetooth 4.2 without DLE has a maximum size of 27 bytes. Therefore the Bluetooth stack has to fragment the L2CAP protocol data on link layer level. And there we believe is the problem which was observed by us. Example: MAX_PDU_SIZE = 162 Size of application data to be sent is 37 bytes which fits in MAX_PDU_SIZE. Size of data on link layer level = 37 bytes + 3 bytes ATT header + 4 bytes L2CAP header = 44 bytes to be sent Link layer data payload = 27 bytes (BLE 4.2 without DLE) -&gt; The 44 bytes to be sent won&#39;t fit in the link layer data payload and therefore the Bluetooth stack has to fragment them in two transmissions (27 bytes + 17 bytes) This leads to the following transmission with two concurrent connections: 27 bytes fragment from connection A 27 bytes fragment from connection B 17 bytes fragment from A 17 bytes fragment from B What we observed is that the reassembly of that fragmentation fails when (at least?) two concurrent connections are active. The fragments on link layer level are mixed between these two connections. The reception of the fragmented transmission shows the following result: 27 bytes fragment from connection A 27 bytes fragment from connection B 17 bytes fragment from A -&gt; reassembled to 27 bytes fragment from connection B + 17 bytes fragment from connection A -&gt; CRC error on application level We believe the problem is in this receive-reassembly handling within the Bluetooth stack when (at least?) two connections are active. Could you please investigate the handling of interleaved fragments from multiple connections and confirm whether this is a stack defect? Best regards, Thorstenhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694597/cc2650moda-cc2650-ble-stack-2-02-08-12-fragmented-notifications-mixed-between-two-connections/6528671Tue, 03 Nov 2026 09:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e150176b-e684-485d-904a-e28358dbc2bfFaizan HabibHi Thorsten, Thank you for reaching out. Does this happen when you reduce MAX_PDU_SIZE to default 27 bytes? Moreover, are you attempting to send payloads larger than 251 bytes? If your app does not require that, I recommend setting the MAX_PDU_SIZE to 255 to avoid fragmentation altogether. Best Regards, Faizanhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1693420/cc2642r-q1-insufficient-negative-resistance-of-crystal-oscillator/6528615Tue, 03 Nov 2026 08:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0da4d17d-7ef5-4da3-b3ff-5422a003de3bCashmere RamosHi Xuanfeng, Increasing the drive strength through software is not possible on this device. You may attempt to retune with the internal cap array (and/or remove load caps if necessary) to reduce CL, but this might shift frequency among other effects so please also check this as well. TI&#39;s absolute minimum for the oscillator to function is 3x ESR so you may proceed at your own risk since it fits that baseline but we recommend having enough margin up to 10x for robust operation. Ultimately if possible, we recommend choosing a different crystal at this time. Best Regards, Cashhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1692251/cc2642r-q1-insufficient-negative-resistance-of-the-oscillation/6528614Tue, 03 Nov 2026 08:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d0794e2f-9eda-4457-a2eb-5aed18b61e53Cashmere RamosHi Xuanfeng, Increasing the drive strength through software is not possible on this device. You may attempt to retune with the internal cap array (and/or remove load caps if necessary) to reduce CL, but this might shift frequency among other effects so please also check this as well. TI&#39;s absolute minimum for the oscillator to function is 3x ESR so you may proceed at your own risk since it fits that baseline but we recommend having enough margin up to 10x for robust operation. Ultimately if possible, we recommend choosing a different crystal at this time. Best Regards, Cashhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694570/cc2745r10-q1-is-dynamic-switching-between-the-dc-dc-regulator-and-gldo-supported-in-cc2745/6528605Tue, 03 Nov 2026 08:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a0803060-dff1-47f1-93ba-cfe701a7aa03Francois CharlotHi team, Here is some background about this request: the system was initially planned to switch from the GLDO to the DCDC during bootloading, then remain in DCDC mode. However, this affected RF performance. So, customer wants the application to switch back to GLDO. The thought is that for the boards that already in the field and for which the bootloader cannot be modified anymore, the application is updated remotely, and this application update switches back to GLDO operation, so the whole application would run with the GLDO. Customer asks if switching back from DCDC to GLDO is valid. I would say that this is OK just by setting VDDRCTL.SELECT = 0. However, the may be special care or caveats to consider here. Also, a footnote in the datasheet table 6-2 states &quot;When the DC/DC converter is not used, the inductor between DCDC and VDDR can be removed.&quot;, so customer asks if it is OK to have this inductor still populated while the application will permanently use the GLDO and if any special attention should be paid while switching back to the GLDO. Best regards, Fran&#231;ois.https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694687/cc2340r5moda-ecad-models/6528600Tue, 03 Nov 2026 08:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2a97214b-1d34-4dfb-a03c-a1d95c654036Diego PHi Patrick, The 3D step file we have for CC2340R5MODA is attached. We do not have a .lbr file for fusion. Please note that the step file does not have the shield. e2e.ti.com/.../CC2340MODA.stphttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694687/cc2340r5moda-ecad-modelsMon, 02 Nov 2026 20:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:35774991-ad93-401b-bbd2-c474f683e98bPATRICK OHARAPart Number: CC2340R5MODA Hello, Are ECAD models available for the CC2340R5MODA? I need the 3D STEP file and a .lbr file for Fusion. Thank youCC2340R5MODATest &amp; Measurementhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694597/cc2650moda-cc2650-ble-stack-2-02-08-12-fragmented-notifications-mixed-between-two-connectionsMon, 02 Nov 2026 14:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:327c8feb-069a-40eb-b866-877eba649269Thorsten OttPart Number: CC2650MODA Other Parts Discussed in Thread: CC2650 Hello, we use a CC2650 central with two peripheral connections, MAX_NUM_BLE_CONNS=2 and MAX_PDU_SIZE=162 . During concurrent transactions, we observe application CRC errors and missing replies. A Bluetooth sniffer recording shows two valid fragmented notifications arriving in this order: First fragment from connection A First fragment from connection B Continuation from A Continuation from B The notification delivered to our application contains the first portion of B’s payload followed by the continuation of A’s payload. We matched these bytes directly against the radio recording. Our investigation of the problem points to receive payload reassembly in the BLE stack. Could TI confirm this issue, provide a defect reference, and supply an official corrected library or supported patch? Thanks in advance!BLE-STACKCC2650MODACC2650Datacom modulehttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1694570/cc2745r10-q1-is-dynamic-switching-between-the-dc-dc-regulator-and-gldo-supported-in-cc2745Mon, 02 Nov 2026 12:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:44885f03-fa67-4ccc-9d03-78fe7f37160bChao LIUPart Number: CC2745R10-Q1 Hello TI Suppport Team, We are using CC2745R10 in our product . And want to check if there is any contraint for GLDO and DCDC switching ? Scenario : We have bootloader , bootloader will be excuted and then jump to app . In bootloader we switch to DCDC , and application we set to GLDO . The resource of VDDR will be GLDO or DCDC? Look forward to your response . Thanks .CC2745R10-Q1https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1689389/cc2340r5-q1-frequent-resets-when-xds-is-connected/6527247Mon, 02 Nov 2026 07:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8efcca29-fec6-4151-a595-c7e72637817dArthur LaurentHello hrkunied, When the device transitions from shutdown to active, the main function is called again. After the BLE stack init is done, App_StackInitDoneHandler will be called. And at the end of this function, you addded: ( void ) Power_shutdown (( uint_fast16_t ) 0 , ( uint_fast32_t ) 0 ); This line will put the device back to shutdown as soon as the initialization is done. Uniflash will then see that the device went back to shutdown and will wake it up again. In my case, I had to read NVS multiple times with Uniflash as the device was getting back to shutdown too fast and it was giving me an error. Best regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1693453/cc2745r10-q1-questions-on-using-gatt_readcharvalue-with-a-known-attribute-handle-on-custom-icall-task/6527038Mon, 02 Nov 2026 02:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c1e0a0d6-3944-4fa9-95c8-102e173336c5Zhitao WuHi Nhung, Yes, attReadRsp_t has your response data. And you can use the same handler for different attribute handles. Because the ATT protocol is a sequential request-response protocol(Vol3 Part F 3.3.2), a response must be following the request before a new request is sent. So the response always serve the request just sent. You need to hold the handle in the request and use it in the response handling. BR Zhitaohttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1689389/cc2340r5-q1-frequent-resets-when-xds-is-connected/6526957Sun, 01 Nov 2026 22:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0867c42d-4079-48c4-a2e1-e5f02361b3e6hrkuniedHello Arthur, Thank you for your assistance. I have one more question to help me understand the behavior. I understand that UniFlash may wake the device from Shutdown mode in order to access NVS. However, I do not understand why this appears to happen repeatedly. My understanding is that once the device has been woken from Shutdown mode, NVS should be accessible. Therefore, I would expect only a single wake-up event. Could you please explain why the device appears to be woken multiple times, sometimes several times per second, while reading NVS with UniFlash? I would appreciate any clarification on this point. Thank you for your continued support. Best regards, hrkunied.https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1693453/cc2745r10-q1-questions-on-using-gatt_readcharvalue-with-a-known-attribute-handle-on-custom-icall-task/6526925Sun, 01 Nov 2026 10:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9951419f-47ee-4a00-b0d8-f24d7d78d8aaNhung HongHi Zhitao Wu, In the gattMsgEvent_t struct, there is a gattMsg_t field containing attReadRsp_t as shown below: typedef struct { uint16 len; //!&lt; Length of value uint8 *pValue; //!&lt; Value of the attribute with the handle given (0 to ATT_MTU_SIZE-1) } attReadRsp_t; Is the response data from a read request stored in this struct?&quot; Can I use a single callback, for example CAClient_GATTEventHandler , to receive read response data for different attribute handles? How do I know which read request&#39;s response triggered this callback? Best regards, Nhunghttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1689389/cc2340r5-q1-frequent-resets-when-xds-is-connected/6526076Fri, 30 Oct 2026 10:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:295cb785-d5e9-4028-9d75-4609cf8a432bArthur LaurentHello hrkunied, We managed to replicate and understand the issue you are facing. When Uniflash reads NVS, it will wake the device up from shutdown using the XDS JTAG connection. This is considered as a PoR and will be stored in the NVS according to your code. Everytime the devices wakes up from shutdown, it goes through Power on Reset and your software executes from the main function again, putting the device to shutdown, and so on... This happens many times per second, explaining the important PoR count in NVS. A potential workaround would be to detect the previous reset reason of the device and use it to only go back to shutdown when needed. In your case, only go to shutdown mode when the previous reset reason is not a PoR. Let me know if you need further help, Best regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1693453/cc2745r10-q1-questions-on-using-gatt_readcharvalue-with-a-known-attribute-handle-on-custom-icall-task/6526057Fri, 30 Oct 2026 09:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:81b1afc6-4e7f-4415-8359-e93752aeddffZhitao WuHi Nhung, 1. Issuing the read with a known handle GATT_ReadCharValue(connHandle, attReadReq_t *, taskId) is the correct procedure when the client already knows the characteristic value handle 1 . static bStatus_t readKnownHandle(uint16_t connHandle, uint16_t valueHandle) { attReadReq_t req; req.handle = valueHandle; // handle you already know // taskId = ICall entity of the task that will receive the response return GATT_ReadCharValue(connHandle, &amp;req, selfEntity); } The call is asynchronous: a SUCCESS return only means the request was queued. 2. Handling the response There is good reference of READ_RSP handling in the example code, find in SDK file examples\rtos\CC2745R10_CS_EVM\ble\key_node\app\app_ca_client.c. Register the GATTEvent handler first, and define the events mask to be handled. BLEAppUtil_EventHandler_t caClientGATTHandler = { . handlerType = BLEAPPUTIL_GATT_TYPE , . pEventHandler = CAClient_GATTEventHandler , . eventMask = BLEAPPUTIL_ATT_MTU_UPDATED_EVENT | BLEAPPUTIL_ATT_FIND_BY_TYPE_VALUE_RSP | BLEAPPUTIL_ATT_READ_BY_TYPE_RSP | BLEAPPUTIL_ATT_HANDLE_VALUE_IND | BLEAPPUTIL_ATT_READ_RSP | BLEAPPUTIL_ATT_ERROR_RSP }; static void CAClient_GATTEventHandler ( uint32 event , BLEAppUtil_msgHdr_t * pMsgData ) { ... case BLEAPPUTIL_ATT_READ_RSP: { // Enable indications CAClient_enabledIndication ( gattMsg -&gt; connHandle , true ); break ; } ... }