This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BOOSTXL-CC2650MA: Simple Central Connection issues

Part Number: BOOSTXL-CC2650MA
Other Parts Discussed in Thread: CC2650MODA, CC2560, CC2650

Hello,

I want to connect the CC2650MODA with a Microchip RN4677. For this reason I use the CC2560MODA Boosterpack .
To test the connections I modified the Simple Central project:

static void SimpleBLECentral_processRoleEvent(gapCentralRoleEvent_t *pEvent)
{
  switch (pEvent->gap.opcode)
  {
    case GAP_DEVICE_INIT_DONE_EVENT:
      {
        maxPduSize = pEvent->initDone.dataPktLen;
        Display_print0(dispHandle, ROW_ZERO, 0, "BLE Central");
        Display_print0(dispHandle, ROW_ONE, 0, Util_convertBdAddr2Str(pEvent->initDone.devAddr));
        Display_print0(dispHandle, ROW_TWO, 0, "Initialized");
        Display_print0(dispHandle, ROW_SEVEN, 0, ">RIGHT to scan");


        bStatus_t test = GAPCentralRole_EstablishLink(DEFAULT_LINK_HIGH_DUTY_CYCLE,
                                     DEFAULT_LINK_WHITE_LIST,
                                     ADDRTYPE_PUBLIC, powerWheelAddrThree_ui);




..................


        attWriteReq_t req;
        bStatus_t testStatus;

        //allocate GATT write request
        req.pValue = GATT_bm_alloc(connHandle, ATT_WRITE_REQ, 1, NULL);
        // if sucesfully allocated
        if ( req.pValue != NULL )
        {
          //fill up request
          req.handle = 58;
          req.len = 1;
          req.pValue[0] = 0x41;
          req.sig = 0;
          req.cmd = 0;

          //send GATT write to controller
          testStatus = GATT_WriteCharValue(connHandle, &req, selfEntity);
          //if not sucessfully sent
          if (testStatus != 0)
          {
            //free write request as the controller will not
            GATT_bm_free((gattMsg_t *)&req, ATT_WRITE_REQ);
          }
        }

I Connect to the Microchip RN4677 after the Stack was initialized. Every 2 Seconds I send a 0x41.
In a active debug session I have no connection issues.
When I run the program not in debug mode the CC2560MODA can hold the connection only a few seconds. Without debug the connection gets always terminated.
In a active debug session I have no connection problems, the CC2560MODA can hold the connection without any problems.
To investigate the data transfer I Used the TI Software “Packet Sniffer”.
In a NON debug Session I see a lot of RETRIES from the Master (CC2560MODA). After a few seconds the slave does not response to that retries.
In a debug Session there are only a few retries. To connection seems stable.
I think it could be a timing problem with the CC2560. I have attached Packet Sniffer data (one from a debug session and one in a NONE debug session).
Can someone please look at these files?

DEBUG_CONNECTION_002.psdNO_DEBUGG.psd

  • Hi Tobias,

    Do you have access to a frequency counter to verify the 32 kHz clock frequency? In the TRM, www.ti.com/lit/pdf/swcu117 , IO chapter, there are instructions on how to output the LF clock on an IO pin. If you have a counter, could you try to output the clock on an available pin and measure it?

    An alternative thing to try is to change the LF/RTC clock source to 24 MHz crystal oscillator in CCFG and see if that resolves the problem.

    Regards,
    Fredrik
  • Hi Fredrik,

    I have insert the commands which were mentioned in the www.ti.com/lit/pdf/swcu117.

      // Initialize application
      SimpleBLECentral_init();
      IOCPortConfigureSet(CLOCK_OUTPUT, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);
      AONIOC32kHzOutputEnable();
    

    But I am not able to run the program. I have the following error:

     undefined               first referenced                
      symbol                     in file                     
     ---------               ----------------                
     AONIOC32kHzOutputEnable ./Application/simple_central.obj

    error #10234-D: unresolved symbols remain
    error #10010: errors encountered during linking; "Simple_ECS_simple_central_cc2650lp_app.out" not built

    Could you tell me which includes are needed?

  • Hello Fredrik,

    I just had a call with the customer. They figured out that they don't see any issue when the "Power save mode" is deactivated, but where not able to compile the above code example yet. Can you please give further assistance to verify the crystal frequency?

    In addition, it seems to be that this issue is similar to this post: e2e.ti.com/.../1856249

    As the module is battery powered, the power safe mode is essential.

    Kind regards,
    Felix
  • Hi Tobias,

    You have to include aon_ioc.h at the top of the file:

    #include aon_ioc.h

    Regards,
    Fredrik

  • Hi Fredrik,

     

    I have measured the clock. See the picture below:

    I have measured the clock with 32.780 Khz. In another post (https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/511175/1856249?tisearch=e2e-sitesearch&keymatch=AONIOC32kHzOutputEnable();#1856249) a customer has a similar problem. After I deactivated the POWER_SAVING I have no connection issues. But for our application we must save energy.
    Could you confirm that with the measured clock is everything right?
    Is the 32Khz clock used to wake up the MODA for BLE events?

    In your first answer you have proposed to change the LF/RTC clock source to 24 MHz crystal oscillator in CCFG.
    Could you tell me the needed steps?

    Regards,

    Tobias

  • Hi Tobias Amann,
    After you connect to Microchip RN4677. Do you discover the all characteristics of Microchip RN4677?
    Your issue can be the 32k crystal (crystal or capacitor). You can try to use the internal 32k crystal that is generated from 24 Mhz. It is supported in CC2650

  • Hi Luu Vy,

    I am transmitting some data to the RN4677 until the connection gets terminated.
    Could you tell me where I can found a reference on how to use the internal 32k crystal?

    Regards,

    Tobias

     

  • Hi Tobias,

    From your measurement it looks like the frequency off. If this really is the case there is a problem with the module. Have you just tested one unit or do you have multiple devices with the same problem?

    Regards,
    Fredrik
  • Hello Fredrik,

     

    I have a second CC2650MODA where I measured the clock (See picture). On this board I have the same problems.
    It only works when I delete the Predefined Symbol POWER_SAVING.

    I have looked at the Technical Reference Manual of the CC2650 which is part of the CC2650MODA (http://www.ti.com/lit/ug/swcu117g/swcu117g.pdf). On page 416 chapter 6.5.1 there are several clocks available.
    I think you want me to measure the SCLK_LF Clock (which is marked yellow in the picture below).

    Could you confirm that you mean this clock when your are talking about the 32Khz clock?

    On page 418 is the Clock Mux show for SCLK_LF. I have checked the registers to verify which clock is muxed on the SCLK_LF.

    DDI_0_OSC:CTL0.SCLK_LF_SRC_SEL = 0x3

    DDI_0_OSC:CTL0.XOSC_LF_DIG_BYPASS = 0x00

    When my suggestions are right I am measuring the External 32.768 Khz Oscillator. And then I think the frequency looks good. Why do you think the frequency is bad?

    With the commands:

      IOCPortConfigureSet(CLOCK_OUTPUT, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);
      AONIOC32kHzOutputEnable();

    Which Clock do I output on a DIO. Is it the muxed SCLK_LF Clock? Or is it the internal LF_RC or the external LF_XTAL Clock?

    Regards,

    Tobias

  • Hi Tobias,

    With the commands provided you will output the SCLK_LF on the DIO pin. Unless you have made any changes to the clock configuration, this clock is sourced from the 32 kHz crystal oscillator. This seems to be confirmed by your register settings.

    Just to confirm: You have not changed any settings in ccfg.c, right?

    The measurements do not look good because the first is 366 ppm off and the second is -397 ppm off. The clock offset is supposed to be within +/- 20 ppm. It does however look like you may have a problem with how you measure the frequency. Could you try using a frequency counter instead?

    Regards,
    Fredrik
  • Hi Fredrik,

    yes that is right. I don’t have changed the ccfg.c file. Now I have used a frequency counter and  I have measured: 32769,71 Hz. Now it is 52 ppm off. Is this deviation permissible regarding to the Bluetooth spec?

    Regards,

    Tobias 

  • Hi Fredrik,

    I had another call with the customer and were discussing about the oscillator issue. For me it is not clear why it is so important that the frequency is very stable. The temperature coefficient of the Low Frequency RC Oscillator is quite high.

    Please see attached the Units from the Launchpad and the Boosterpack. Are those affected by the issue, described here:

    Thank you and kind regards,

    Felix

  • Hello team,
    can you please follow up with our questions?
    Thank you and kind regards,
    Felix
  • Hello Felix,

    Can you call the following in your application init after ICall registration:

    HCI_EXT_SetSCACmd(60);

    This spec allows up to +/- 500ppm however the stack needs to be configured with the actual PPM value.

    Also, since you ported the SimpleCentral application on the CC2650MODA, did you configure the antenna for the 5XD configuration?

    Best wishes
  • Hello,

    I am the customer of Felix. I have added the command after the ICall registration. This command has not leaded to an improvement. No I don’t have changed any antenna configuration. I have followed the TI instructions (http://www.ti.com/lit/an/swra534/swra534.pdf). I think the antenna is not the Problem. When I remove the predefined symbol POWER_SAVING I have no connection issues.
    I have measured the SCLK_LF with a freqeuny counter. I have measured a 32769,71 Hz. When you say the Bluetooth spec allows +/- 500ppm then the frequency is with +52 ppm inside the range.

    Regards,

    Tobi

  • Hello Tobi,

    The symptoms are indicative of a sleep clock issue, although there is not enough information to determine root cause. To simplify the SW, can you run the simple_peripheral sample app and apply changes from SWRA534, including changing the antenna to CC2650EM_5XD, with the following suggested connection parameters:

    #define DEFAULT_DESIRED_MIN_CONN_INTERVAL 300
    #define DEFAULT_DESIRED_MAX_CONN_INTERVAL 320
    #define DEFAULT_DESIRED_CONN_TIMEOUT 400

    Also, in your app, it would be good to periodically check that the SCLK is locked to the 32k xtal via this API:

    if(OSC_XOSC_LF == OSCClockSourceGet(OSC_SRC_CLK_LF)) {}
    taken from the processors.wiki.ti.com/.../CC26xx_HW_Troubleshooting wiki article.

    You should see minimal dropped packets and no loss of 32k xtal clock.

    Best wishes