• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 51 subscribers
  • Views 2116 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.

Disconnect right after connect And Connect takes long time

Harald Ilg
Genius 3060 points
Other Parts Discussed in Thread: CC2640

Hy,

since starting to work in a "productive" environment, one issue, that I am observing since a long time, starts bothering me:

I see two strange effects on connecting to my device. It is the same thing, no matter if I use BTool or any other (Android, iOS) device

1) Disconnect right after connect

When trying to connect to the device, apparently the connection is established for a very short time, then disconnected instantly. This happens about once of 100 connections (1% of all cases)

In BTool log, I see the GAP_EstablishLinkRequest from Central, 1s later, I see "Device Connected", 1s later I see "Device disconnected"

I can't see a TX right before the "Device disconnected", so apparently, the device itself disconnects.

/cfs-file/__key/communityserver-discussions-components-files/538/btoolLogUnsuccessful.txt

/cfs-file/__key/communityserver-discussions-components-files/538/btoolLogSuccessful.txt

The effect comes more often when I connect / disconnect / connect in a quick sequence

2) Connection takes very long to be established

Usually, the time between "GAP_EstablishLinkRequest" and "Device connected" is only a couple of milliseconds. But ever once in a while, it takes up to 10s until the device is connected.

Does this description ring any bell? Any hints, where I could try to change parameter to overcome these effects?

My environment: CC2640, CCS, Peripheral (based on SimplePeripheral), own HW

Best regards

Harald

  • 0
    TI__Guru** 105180 points
    Hello Harald,

    These symptoms can be related to marginal HW conditions, i.e., crystal or power. Do you see the same failure when disabling POWER_SAVINGS? Also, can you review the items in the CC2640 HW Troubleshooting article on the BLE Wiki?

    Best wishes
  • 0 in reply to JXS
    Genius 3060 points

    Hy,

    thanks for your quick response and the hint about HW issues. Actually, that might be the problem: We use 12pF for the 32kHz Quartz, which is at the upper end of the recommended range

    Do you recommend any other value here?

    > Do you see the same failure when disabling POWER_SAVINGS?

    Yes, I see the same effect. I removed the predefinded symbol "POWER_SAVINGS" for app and stack project. I see a DC current of 1-2mA, but everything else remains identical. Does that mean, that the HW issue can not be the reason? Is there any other way of verifying, that the HW could be the problem? Oscilloscope?

    What other reasons could there be for that effect if it is not the HW? Where would you recommend to debug?

    Best regards

    Harald

  • 0 in reply to Harald Ilg
    TI__Mastermind 18780 points
    What is the datasheet value for the load capacitance for the crystal you use? Have you verified the frequency of the crystal (output the signal on a DIO pin, see TRM section 11.3.3. Since disabling power savings does not work, it may be something different than the 32k crystal. Have you tested your code on our HW? Does that work? Have you tested your RF performance?
  • 0 in reply to CHS
    Genius 3060 points

    Hy Charlotte,

    unfortunately, I am not much of a HW guy. Frequency scares me if higher than 20Hz... But I try to answer as best as possible:

    > What is the datasheet value for the load capacitance for the crystal you use?

    We use an Epson Q13FC13500003 Quartz, the datasheet says 7pF, 9pF, 12.5pF. Whatever that means

    > Have you verified the frequency of the crystal (output the signal on a DIO pin, see TRM section 11.3.3.

    No, I have not, but I will. What is the expected outcome? Should it toggle constantly? Or only during awake time of the controller?

    >Since disabling power savings does not work, it may be something different than the 32k crystal.

    Yes, that's kind of my feeling, too. Every single CC2640 design that I found does the quartz circuitry exactly as we do. But what other reasons could there be?

    > Have you tested your code on our HW? Does that work?

    Unfortunately, I don't have an original TI HW available any more. And even if I had, I see quite some effort in porting my software back to the TI hardware. I have several devices on twi I2C busses, LEDs etc.

    > Have you tested your RF performance?

    It feels quite normal. The rssi values show normal numbers. And once connected, I see the expected througput, i.e. in burst data download or OAD. What else could test the RF performance?

    Best regards

    Harald

  • 0 in reply to Harald Ilg
    TI__Guru** 105180 points
    Hello Harald,

    While you are providing answers to CHS's questions,

    Have you tried disabling your external peripherals in SW to see if there's an effect? Excessive time in an HWI/SWI could preempt the Stack which could result in non-ideal behavior. It would be helpful to run the SimpleBLEPeripheral SW on your board without any ext. peripherals enabled. If the LE connection is solid, then start enabling peripherals one by one.

    RF testing can be done by completing the RF-PHY tests, see the PTM wiki article. If you are not sure how to run these tests, please consider using the services of a qualified RF test facility. RSSI alone is not a definitive test.

    Best wishes
  • 0 in reply to Harald Ilg
    TI__Mastermind 18780 points
    When you by the crystal, you specify what load capacitance you want (7, 9 or 12 pF). The external load capacitors that you add on your design must match the load cap for the crystal you have ordered for the frequency of the crystal to be correct. So in our ref design, the crystal we use has a specified load capacitance of 7 pF, thus we used two 12 pF capacitors to get the correct load for the crystal (Cload= 1 / (1/12 + 1/12) + Cparacitics)

    As JXS says, RSSI alone is hard to use to verify the RF performance even though it will give you a pointer. Do you have a BLE tester or any RF test equipment? What is the range you get?
  • 0 in reply to CHS
    Genius 3060 points

    Hy,

    thanks for all your help. Unfortunately, I have no success so far in this matter.

    As we kept strict to all the available reference designs and use the same quartz I feel pretty sure, that the 12pF capacitor as load capacitor for the 32kHz quartz is correct. Still, on one board, we have changed the capacitors to 10pF each. This board has the exact same behaviour when it comes to immediate disconnects, the only difference is that the RTC seems a bit slower than on devices with the 12pF (about 4s per day).

    As now reading all relevant forum entries again I am a bit confued: The HW troubleshooting names the 32kHz quartz to be responsible, other posts speak about the HF (24MHz / 32MHz) that they needed to change to overcome this issue. Is the slow one the correct one?

    Might there be other reasons for these disconnects? SW issues? The problem appears in about 2% of all connects (396 errors in 19.220 trials), I cannot see any dependencies to device, other BLE communication, temperature, battery voltage, etc.

    >Have you tried disabling your external peripherals in SW to see if there's an effect? Excessive time in an HWI/SWI

    > could preempt the Stack which could result in non-ideal behavior

    I have different variants of devices. There is one type, that does nothing but advertising, no sensor communication, no interrupts, no nothing. Same behaviour.

    I have also made some experiments with adjusting the 24 MHz load cap the as describe here, no success either.

    Any help appreciated

    Regards

    Harald

  • 0 in reply to Harald Ilg
    TI__Mastermind 18780 points
    can you try disabling the internal DCDC in your SW?

    can you test your boards using SmartRF Studio?
  • 0 in reply to CHS
    TI__Mastermind 18780 points

    and also maybe post your schematic and layout for a review. If you do not want to post them here, you can send me a friend request so you can send me them off line. 

  • 0 in reply to CHS
    Genius 3060 points

    Hy Charlotte,

    >can you try disabling the internal DCDC in your SW?

    I am not too sure how to do this. In TRM I find "Alternatively, the internal Global LDO can be used instead of the DC-DC regulator, but this increases the current consumption of the device. In this mode, disconnect DCDC_SW and connect VDDS_DCDC to the VDDS supply. The Global LDO is connected internally to the VDDR pin, which must be connected externally to the VDDR_RF pin. The Global LDO must be decoupled by a µF-sized capacitor on the VDDRnet." (6.1.2.1)

    Do you mean this? This is not possible because I can't change the hw at this level.

    >can you test your boards using SmartRF Studio?

    What do you mean with test? I can connect to SmartRF Studio.What to do there?

    Regards

    Harald

  • 0 in reply to CHS
    Genius 3060 points

    Hy,

    this is the relevant parts of my hardware

    Is that what you need for further support?

    Regards

    Harald

  • 0 in reply to CHS
    Genius 3060 points

    Hy Charlotte,

    I finally managed to measure the 32kHz signal on an IO port after activating it as described in TRM 11.3.3

    Statistically I see a constant frequency of 32.770kHz, but actually, it jitters quite a bit: The slowest I've seen is 32,743kHz, the fastest is 32,819kHz. But this might be due to my measuring equipment: I use an 200MHz logical analyzer, trigger on high state longer 16.05us to find the slowest and trigger on high state shorter 15.24us to find the slowest. Than I add high and low duration and use the reciprocal value as frequency.

    I never saw any longer droputs of the frequency, also not during the error state (immediate disconnects)

    This seems OK. What do you think?

    Regards

    Harald

  • 0 in reply to Harald Ilg
    TI__Mastermind 18780 points
    Sorry for the delayed reply but I have been out of office. When I asked you to try to disable the DCDC, that was meant as a test not as a solution. You can disable the DCDC in SW in the ccfg file, no HW changes needed. This is because with a non-optimal DCDC layout, the RF performance can be reduced. It is hard to say much on your HW without seeing the GND layers, can you send me a more detailed pic with the GND layers in a message? Schematic looks ok. Have you updated your SW so that it uses the correct front-end configuration (in your case differential with external bias)?

    It would be could if we could somehow verify the RF performance of your board. That is why I refer to SmartRF studio. Do you have any of our HW available so that you could do some measurements to compare performance? This way you could also verify the 32kHz clock with your measurement set-up.