• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 3600 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.

CC26XX disconnecting (reason 0x08)

Christian Mellor
Intellectual 260 points
Other Parts Discussed in Thread: CC2650

Hello,

I have developed a custom board based on the 4x4 CC2650 chip using BLE (with the antenna taken from the SensorTag reference design, and the remainder of the circuitry taken from the uTag reference design). The antenna is operating in single ended mode.

Starting from the SimpleBLEPeripheral project, I have written custom firmware and used the debugger on the CC2650 Launchpad to program my board via CCS.

The issue I am having is that using all the default settings in the SimpleBLEPeripheral project, my device boots up and I can connect to it via an iPhone 6 (either using TI's multitool app, or LightBlue Explorer). I can subscribe to notifications and read them perfectly.

However, when using a Macbook Air, the connection drops after 7 seconds every time with the error code - 0x08.

If I flash the same program (with diff board file) to the LaunchPad, both the laptop and the phone can connect?

Has anybody experienced a similar issue before? I am assuming it could be down to the hardware - but if it were, I would expect it to fail when used to connect to the phone too.

(I currently don't have access to a spectrum analyser)

Kind regards,

Christian

  • 0
    TI__Guru** 105180 points
    Hello Christian,

    Marginally performing RF could appear to work well with one peer device but not with another, so we can't assume the HW/RF is correct just based on a test with the iPhone. Based on your description, it appears you have used the correct board file with the single-ended RF configuration.

    Can you take a BLE air sniffer trace with the Mac connection? This would be a good starting point. Beyond that, the HW troubleshooting tips on the BLE wiki will need to be performed. You can also post your schematic & layout for review .

    Best wishes
  • 0 in reply to JXS
    Intellectual 260 points

    Hello,

    I don't have access to a Packet Sniffer at the moment (I am trying to get my hands on the 2541 dongle). I have used the Mac Developer Tools' Packet Logger though, which basically logs everything from the Mac's point of view.

    There are a couple of commands that it is logging that I am unsure about: firstly - LE Create Connection Cancel, that my device sends is basically rejected by the Mac with status disallowed - I tried Googling what this command is supposed to do but I couldn't find it.

    Secondly - there is a read request at 15:47:53.597 that appears to go unanswered - then the connection times out after that (exactly five seconds after, which the default supervisor timeout period for the Mac - I don't think this can be changed?). My thinking is that there is no packet transmitted from the device after this request, and it is this read request is causing an error on the device (a packet sniffer would confirm my suspicions here).

    I can send you my layout + schematic if you would like to take a look, I am next going to try and use the SmartRF06 board + CC2650EM + BTool to see if I can connect to the device in that way.

  • 0 in reply to Christian Mellor
    TI__Guru** 105180 points
    Hello,

    Yes, a air sniffer trace would help confirm if the Mac is Nacking a packet. The OSX log is not providing details as to what is occurring at the Link Layer. I would also recommend following the check items in the CC26xx HW Troubleshooting BLE wiki article as crystal stability can lead to issues as described. It may be that the iOS device has a wider sleep clock accuracy + faster default conn interval thus it's able to keep the connection going by accounting for the peripheral's sleep clock inaccuracy. Just a guess at this point.

    Best wishes
  • 0 in reply to JXS
    Intellectual 260 points

    Hello,

    Hopefully the 2541 dongle will arrive tomorrow and I can use that as a packet sniffer.

    As for the HW Troubleshooting Wiki - I have checked all of them, however I suspect that because I have used a design without the low frequency oscillator the two devices end up being unable to talk to each other as this device wakes up too late. (As for the main crystal, I am using an Epson TSX 3225 - do I need to alter anything in the firmware to allow for the capacitance of this crystal?)

    This is somewhat confirmed by using a CC2650-EM and SmartRF06 board and BLE Central flashed to it, I can connect (intermittently) and it either fails to connect sometimes with code 62 or disconnects with code 08 (timeout), and similarly using HostTestApp + BTool (see screenshot).

    If this is an issue with the timing and crystals, what options do I have in software to rectify this, (as in the long term I will obviously redesign the board and include a low speed crystal)? I have tried increasing the clock +/- accuracy in the firmware, but this hasn't had any noticeable effect on the issue.

    Do you recommend any additional steps?

  • 0 in reply to Christian Mellor
    TI__Guru** 105180 points

    Hello,

    An external 32kHz crystal is required for BLE Stack SDK releases 2.0 - 2.1.1 when establishing a BLE connection. The next SDK release will support BLE connections (peripheral role) without the need for an ext 32 kHz LF crystal. This feature also requires using a supported silicon revision as noted in the the CC26xx errata document, SWRZ065.

    Best wishes

  • 0 in reply to JXS
    Intellectual 260 points

    Hello,

    I made a stupid mistake before - I hadn't selected the correct setting in the CCFG to use a LF clock derived from the HF external crystal. After changing this setting the device can now correctly connect to both a computer and a phone (oddly it still struggles to maintain a connection with another CC2650 via BTool, I am assuming this is due to a stricter connection window on the CC2650 EM firmware as opposed to the more lenient ones in both the MacBook and iPhone - but for now it will suffice as a testing device).

    I have also attached packet sniffer data for the connection between the iPhone and the device. The first connection and data transfer event in the file is between iPhone and SensorTag 2, and the second event is between my device and an iPhone. Does this all look okay?

    ttpsd.psd