• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 673 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.

RTOS/CC2630: Specs and functional description of the CC26xx recharge algorithm

David Terlinden
Prodigy 30 points

Part Number: CC2630
Other Parts Discussed in Thread: CC2650

Tool/software: TI-RTOS

Hi,

currently we're investigating on some issues causing the CC2630 to hang up in standby.

To ensure proper function and lifetime for a >10k series with potted PCB and disposable battery, I want to understand the recharge algorithm. Is there any documentation on this except all the small obscure pieces from datasheets and user guides?

If not, I would like you to shed some light on it and answer the following questions:

1. See: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/529071/1926606 In that post you state, that the recharge interval is calculated every period depending on the VDDR threshold. I think this is not correct. Instead the next period will be calculated prior to the next standby. This takes the last maximal period (see RECHARGESTAT register) and some other parameters (temperature, bypass cap and sleep current ect.) into account . That means, if (for any reason) the recharge period is to long for the given capacitance and discharge current at VDDR rail and VDDR falls below the fixed (but undocumented) threshold, just the current period will be stored for the calculation after the next wake-up. The period will increase further by the given rate until the maximum value is reached (see RECHARGECFG register). This might lead to an under-voltage at VDDR. Am I right?

2. What is the value of the VDDR_threshold?

3. Is there a VDDR brown-out detection? If so, what is the threshold and does it have to be enabled explicitly?

Thanks!

// Dave

  • 0
    TI__Guru** 106705 points

    Hi David,

    David Terlinden said:
    1. See: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/529071/1926606 In that post you state, that the recharge interval is calculated every period depending on the VDDR threshold. I think this is not correct.

    What I wrote in the post you link to is correct. For every recharge event, the VDDR voltage is measured, and the length of the next recharge interval adjusted. This you can easily measure by using a Power Analyzer. 

    David Terlinden said:
    Instead the next period will be calculated prior to the next standby. This takes the last maximal period (see RECHARGESTAT register) and some other parameters (temperature, bypass cap and sleep current ect.) into account .

    This is also true. The last recharge interval length is used to calculate the initial interval of the next Standby period.

    David Terlinden said:
    That means, if (for any reason) the recharge period is to long for the given capacitance and discharge current at VDDR rail and VDDR falls below the fixed (but undocumented) threshold, just the current period will be stored for the calculation after the next wake-up. The period will increase further by the given rate until the maximum value is reached (see RECHARGECFG register). This might lead to an under-voltage at VDDR. Am I right?

    No, that is not correct because the VDDR voltage is measured for every single recharge.

    David Terlinden said:
    2. What is the value of the VDDR_threshold?

    Around 1.5 V.

    David Terlinden said:
    3. Is there a VDDR brown-out detection? If so, what is the threshold and does it have to be enabled explicitly?

    Not in Standby.

    Regards,
    Fredrik

  • 0 in reply to Fredrik K
    TI__Guru** 106705 points
    Hi David,

    I managed to overlook the fact that you do actually have devices which are hanging. Can you share some more details about these? How do you know they are hanging in Standby? What is the current consumption in the hanging state? What is the supply voltage?

    Regards,
    Fredrik
  • 0
    TI__Mastermind 21630 points
    Hi,
    Can you explain the conditions/scenario when you are see the hangup issue?

    Generally the TI-RTOS automatically enters power down when all threads are closed and before doing so the algorithm calculates the worst case VDDR current consumption and then sets the initial and maximum recharge periods.
  • 0 in reply to Fredrik K
    Prodigy 30 points

    Hi Fredrik,

    thanks for your reply.

    Fredrik K said:
    What I wrote in the post you link to is correct. For every recharge event, the VDDR voltage is measured, and the length of the next recharge interval adjusted. This you can easily measure by using a Power Analyzer. 

    OK that's correct. The period is increased or decreased by the given percentage (6.3%) dependent on VDDR over or under the threshold.

    To cause a hang-up we needed to increase the leakage current by extensive condensation on the board. So this wasn't our problem. Instead I had to discover that the CC2650 Launchpad, which we use as JTAG probe for debugging and production, pulls the TCK line to low level after the transaction is finished. That leads to a lot of falling edges on the TCK line during disconnecting the JTAG connector. Thanks to the ICE-Melter the JTAG keeps awake an consumes >400µA. Another matter...

    Back to the DC/DC and recharge topic: Within the comments in sys_ctrl.c there are paragraphs of a specification mentioned. Where can I find this spec, in case we have further issues with the power supply in standby mode?

    Thanks!

    Best,
    Dave

  • 0 in reply to David Terlinden
    TI__Guru** 106705 points
    Hi Dave,

    If extensive condensation is a risk in your application you should probably consider some kind of conformal coating.

    Interesting finding on the TCK signal when unplugging the JTAG connector, I have not seen that reported as an issue before. While a proper reset, either PIN- or BOD/POR- should take care of that, I would also like to point out that the LaunchPads are designed as a development tool and not for production programming usage.

    The spec points refer to internal design specifications for the device. Should you have any other issues in the future please report them here on the forum.

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

    Hi Fredrik,

    Fredrik K said:
    The spec points refer to internal design specifications for the device. Should you have any other issues in the future please report them here on the forum.

    This isn't a surprise. It seems to be common practice not to provide complete documentation.

    Fredrik K said:
    Interesting finding on the TCK signal when unplugging the JTAG connector, I have not seen that reported as an issue before. While a proper reset, either PIN- or BOD/POR- should take care of that, I would also like to point out that the LaunchPads are designed as a development tool and not for production programming usage.

    To verify this, we just purchased a stand-alone XDS110. Same issue. Even setting "JTAG Signal Isolation" to "Do isolate JTAG signals at final disconnect" in the ccxml doesn't change the behavior of the JTAG pins after flashing. A pin-reset is not possible AFTER the debug connector is disconnected. Thus a power-on-reset is the only option to guarantee a safe state. For some devices with soldered batteries this is even no alternative. So currently we are considering an additional line driver for the TCK line to switch it to high-z before disconnection. This is underwhelming.

    Do you have any suggestion to avoid this hack?

    Thanks!

    Dave

  • 0 in reply to David Terlinden
    TI__Guru** 106705 points
    Hi Dave,

    One option would be to use the built-in ROM bootloader for production programming. You can find more information about it in the Technical Reference Manual and this application note: www.ti.com/.../swra466 .

    Another alternative is to use a proper production programmer, for example from Elprotronic: https://www.elprotronic.com/

    Regards,
    Fredrik