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

CC2540 POWER_SAVING problems

kowalski5233
Intellectual 420 points
Other Parts Discussed in Thread: CC2540

Hi all

I have and had some problems with POWER_SAVING mode on the HostTestRelease project for the CC2540.  So let me start at the beginning.

Back in the day I set it up to not use flow control and defined GATT_OFF_CHIP I think it was called to let our processor handle the table and replies etc etc.  Everything works awesome and we've been using it like this and building on our side for the last year almost in numerous very successful prototypes.

We are currently at the point were power consumption could severely be improved if we sleep the CC2540, as currently it is the biggest consumer.  I have in the past played with it and struggled to wake the chip on UART, had to spend time on other things and there it was left.  Until now.  Took me a while again to remember to pull the RTS low to wake the chip.

Next problem was that the CC2540 would only respond if RTS is low.  This is a problem as our processor will never know when the CC2540 has a connection request unless we either keep RTS low, which will never allow the chip to sleep, or poll it, which will have severe user experience lag implications.  After some scratching around I found where the CTS is enabled on the CC2540 and removed it.

Now it looks like everything UART and sleep related is working perfectly, but I struggle with connections being dropped after they're made, anything between mere seconds to almost a minute after the connection was made.  Debugging central device reveals the connection has timed out unexpectedly, sniffing the packets reveals our peripheral with the CC2540 stops the 'handshaking' process, while debugging our peripheral's processor shows that the CC2540 did decide to terminate the link, but currently there are now further details.  These three tools are also not synced, so it's hard to see what happens when on each of them relative to the other.

Any ideas?

I have also posted some here in the event that some of the people who struggled with similar problems in the past could help me out : http://e2e.ti.com/support/wireless_connectivity/f/538/t/310686.aspx

  • 0
    TI__Expert 4565 points

    My guess is that there may be an issue with the sleep timer and maybe the crystal circuitry of XTAL2 which is the 32.768kHz source for the sleep timer. If the sleep timer is not accurate then the CC2540 may get out of sync with the connection interval of the link. This would look like a connection time out on both the CC2540 and your other device.

    -Matt

  • 0 in reply to _mk
    Intellectual 420 points

    We're using the internal RC oscillator for 32.768kHz.  Would you reckon this could be where the problem lies?  I've read about problems with the RC oscillator and sleep mode with advertising on older stacks, but mine works perfectly with v1.4.0.  The basic board has been designed some time back and we had to throw everything off it that we could, so didn't add the crystal. 

    If this my problem, is there some workarounds you could suggest other than making and populating new boards?

  • 0 in reply to kowalski5233
    TI__Expert 4565 points

    Unfortunately the only work around that will give you a reliable solution is to not use the POWER_SAVING mode.

    You might be able to increase the amount of time before the disconnect occurs through LL_EXT_SetSCA(). This allows you to spec the sleep clock accuracy and basically increases the window of time over which the device will wake up for TX/RX (which in turn sacrafices some power savings by not being in PM2 as long). It's not a solution or work around but may give you more than a minute before the link terminates.  

    -Matt

  • 0 in reply to _mk
    Intellectual 420 points

    Hi Matthew

    Thank you for all your feedback.

    We have a 32.768kHz crystal elsewhere on the board for a RTC on our main micro.  I made a quick mod and tried sharing the crystal with the CC2540 and set up the CC2540 to use the crystal instead of the internal RC and it worked perfectly straight out the bat.

    Thanks again for the guidance.

    JD