• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 2765 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2650: BLE connection error

Jeremy Roy
Prodigy 50 points
Part Number: CC2650
Other Parts Discussed in Thread: CC2640

Hi there,

Summary:

I'm experiencing an error with a CC2650 RSM when trying to connect to it.  The CC2650 RSM is mounted on a custom-built board of which we have two prototypes.  The first board works fine, whereas the second board is experiencing an error.

Problem:

I've run the simple-peripheral project on both boards.  The first (working) board is able to operate the I2C module and sensor controller, advertise itself, establish a connection, and complete a GATT discovery procedure.  The second board is also able to operate the I2C module and sensor controller, as well as advertise itself.  However, when trying to establish a connection to the second board using gatttools (BlueZ 5.23), I get the following error: "Error: connection error: Function not implemented (38)".

I've compared the flash on both boards and found that the only difference is within page 30 (CCA) bytes 4:19, 24:39.   Every time I re-flash one of the boards the contents in this section changes.  I don't know exactly what information is contained within these bytes, but I do not suspect that this is the source of the error.  Can anyone specify what information these bytes contain?

I have also tried running the project only from flash, without using TI-RTOS ROM modules, but the error still persists.

At present, I suspect that the error resides within the RF Core.  After all, the BLE connection is established and maintained by the RF Core.  Furthermore, I suspect that the problem within the RF Core originates from it's ROM since the function that is apparently "not implemented" should be located within the RF Core's ROM.

I am currently at a loss of how to proceed.  I do not know of any methods to inspect the RF Core's ROM (is this even possible?).  However, I don't want to scrap the board if it is salvageable.  Any suggestions or insight would be greatly appreciated!

Thanks,

Jeremy

  • 0
    TI__Guru** 106705 points
    Hi Jeremy,

    Have you verified the accuracy of the RTC in your designs?

    Regards,
    Fredrik
  • 0 in reply to Fredrik K
    Prodigy 50 points

    Hi Fredrik,

    Thank you for your recommendation of looking into our design's RTC.  We are still experiencing some issues and would appreciate your input.

    It turns out that the 32 kHz XTAL in our design wasn't starting up on the second, non-functioning board.  The oscillator (ABS05) has the following specifications:

    Frequency: 32.768kHz

    Operating Mode: Flexural Mode(Tuning Fork)

    Frequency Tolerance: ±20ppm

    ESR: 90 kΩ

    Load Capacitance: 12.5 pF

    Drive Level: 0.5 μW

    Although the load capacitance of 12.5pF is out of the CC2650's spec, we thought we could get by with it.  The ABS05 does, after all, work on one of our boards, and the FC-12M oscillator that TI recommends for the CC2650 also has a load capacitance of 12.5pF.

    On both boards, the ABS05 was loaded with a 12pF capacitor on either terminal.  We realized that each terminal should be loaded with 24pF to get a load capacitance of 12pF.  We modified the non-functioning board so that each terminal of the ABS05 was loaded with 24pF.  This didn't solve our problem.  For a sanity check, we also tried removing the load capacitors entirely.  The problem still persisted.

    We tried rigging up a third board with the ABS05 oscillator.  The ABS05 on this board also didn't start up.

    We ended up buying an alternative oscillator with a load capacitance of 7pF to make our design meet the CC2650's specifications.   We soldered the new oscillator onto the second board and loaded each terminal of the oscillator down with 12pF to get a load capacitance of 6pF.  On board power up, the new oscillator still failed to start.

    We've verified that none of the pins on the 32kHz XTAL circuit are shorted and that everything is making a proper connection.

    We are stumped and can't figure out how to move forward.  Any advice would be much appreciated.

    Thanks,

    Jeremy

  • 0 in reply to Jeremy Roy
    TI__Guru** 105180 points
    Hello Jeremy,

    Have you verified that your load caps are dimensioned correctly for the 32k xtal to resonate correctly? Attaching your layout would be helpful.

    Also, I recommend running the simple_peripheral application with modifications suggested in the "Running the SDK on Custom Boards" Initial Board Bringup section of the SW User's Guide:

    software-dl.ti.com/.../index.html

    Although this guide is for a newer SDK release, the same concepts apply, including configuration of the RF Front End which must match your layout correctly.

    Note that page 30 is the SNV section, that is why you see differences.

    Best wishes
  • 0 in reply to JXS
    Expert 1690 points
    You can try using the internal crystal - the CC2640 should ignore the external one if you compile your project with USE_RCOSC, then you can at least isolate the issue away from the external 32kHz crystal. You have to verify that the version of the chip reliably supports the internal crystal as apparently some of the earlier ones don't work.
    Running Bluetooth low energy on CC2640 Without 32 KHZ Crystal - www.ti.com/.../swra499b.pdf
  • 0
    Expert 2225 points

    Hi Jeremy Roy,
    According to my experience, the reason is crystal. You can switch to use internal crystal to check it again.

  • 0 in reply to JXS
    Prodigy 50 points

    Hi JXS,

    We have verified that the load caps are dimensioned correctly for both the old ABS05 and the new a 9HT12-32.768KDZY-T.  I've already run the simple_peripheral application with the suggested modifications.  Still wasn't able to establish a BLE connection on board 02.

    We tried soldering the new 32kHz XTAL to a third board with one 12pf load capacitor on each terminal.  This board previously had a ABS05 32kHz XTAL installed (wasn’t working) which we replaced with a 9HT12-32.768KDZY-T.  After the re-work, the third board was able to establish a BLE connection, sometimes.  I haven’t been successful in characterizing the third board’s connection reliability.  However, it seems that once the board is able to establish a connection it will be able to re-connect indefinitely until board power down.  If no connection is possible on board power up, resetting the board via the Smart RF Flash Programmer and Debug Devpack seems to permit BLE connection.  We're still trying to figure out why this is the case.

    I tried what  suggested and ran our custom software using the RCOSC as the source for the 32.768kHz clock on board 02.  Board 02 was able to establish a connection and perform GATT transactions. 

    We're now certain that the source of the problem is the oscillator circuit.  We're now trying to determine whether or not this is a layout problem.   I'll report back here if we run into any further roadblocks.  Thanks for the help!

  • 0 in reply to Jeremy Roy
    TI__Guru** 105180 points
    Hi Jeremy,

    Looks like you are on the right track. One quick test you can do is to disable power saving / inhibit standby by changing the predefined symbol to xPOWER_SAVING. This will keep the MCU from entering standby and won't require the 32k xtal for sleep timing.

    I would also recommend you test your 24MHz crystal accuracy by measuring the RF stability with SmartRF Studio 7. Remember not to probe the xtal directly.

    Best wishes