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.

Linux/CC2564C: Power consumtion issue

Part Number: CC2564C

Tool/software: Linux

Hello,

In our project we are using PAN1326C module which is based on CC2564C TI chip. As a software stack we are using Bluekitchen BT Stack which is running in Linux. We are using posix-h4 port with eHCILL enabled. We modified BT init script and changed inactivity_timeout parameter from 20ms to 1sec.

For our needs we need to advertise both BLE and BT-Classic connections. From CC2564C datasheet, when neither BLE nor BT-Classic advertisements are active -- I would expect that chip should not consume more than 114uA@3.6V.

In sleep mode (echo mem > /sys/power/state) our device consumes ~4.5mA@12V when BT chip is in shutdown state. When we start Bluekitchen stack and turn ON BT chip (w/o any BT and BLE advertisements enabled) -- entire power consumption grows up to ~6.6mA@12V which is way too much.

In terms of Bluekitchen API we turn off advertisements in the following way:

gap_discoverable_control(0); // Classic
gap_connectable_control(0); // Classic
gap_advertisements_enable(0); // BLE

Could you please advice something we could take a look in order to reduce power consumption?

Thank you in advance,
Vadim

  • How are you making the power measurements? Are these just for the BT module or for the entire system?

    Thanks
  • Hi Hari,

    We are measuring entire system.

    Best regards,
    Vadim
  • Hi Vadim

    Could you try to measure only the CC256x module? Maybe other stuff draws power as well. Any LEDs? :)

    Could you make a power trace over time that also show n_shutdown and the UART lines sending the init script and then going into eHCILL mode?

    Best

     Matthias

  • Hi Matthias,

    > Could you try to measure only the CC256x module?
    Unfortunately, we can't measure it separately from entire system.

    > Maybe other stuff draws power as well. Any LEDs? :)
    There are no any LEDs on our device. Currently, it does not look like somethings else could drain the current.

    > Could you make a power trace over time that also show n_shutdown and the UART lines sending the init script and then going into eHCILL mode?

    A few words about our device. It has modem on board and we cannot control its current consumption directly. So, spikes on a graph are produced by modem.

    Attached file has two pages -- 1st one reflects current consumption picture we would expect, 2nd page -- what we actually have at the moment.

    We have localized the problem approximately. Currently, we subscribed to chip init callback with hci_set_control(). In the callback we do the following:

    (1) Pull down n_shutdown
    (2) Wait 200 ms
    (3) Pull up n_shutdown
    (4) Wait 200 ms
    (5) Return control back to BT Stack.

    Such approach results in picture shown on page 2 (high current consumption, 6.8 mA on step 4).

    However, if we do n_shutdown pull up before BT stack has started (and do nothing in "init" callback) -- we actually have expected current consumption (page 1, 4.7 mA on step 5).

    What could be wrong here?

    Best regards,
    VadimBT_Power_consumption.pdf

  • HI Vadim

    Thanks for the plots.

    When looking at the second page, steps 1-3 look ok, but we would expect around 4.9 mA (state 1 + delta(2->3)), right?

    No idea what's wrong or how to explain the difference between both runs. From the plots there's additional power drawn in 2/step 5 but it's unclear if that's caused on the CC256x or on the linux board.

    I'd suggest to use an external CC256C (or just B - there's a ready-to-use CC2564B Boosterpack with 3.3 V) and connect that to a desktop Linux via an FTDI USB-to-UART. In such a setup, you can run your Bluetooth code while directly measuring the power consumption of the CC256x.

    Do you receive the advertisements in both cases?

    Cheers

      Matthias

  • Hi Matthias,

    We found the solution. The problem was that we had improperly configured UART pins in kernel device tree definitions.

    Thank you,
    Vadim

  • Hi Vadim

    I'm glad you've identified the problem (and were able to fix it). I was about to ask if linux board is able to fully disable the UART, but forget to post about that.

    Nevertheless, using an external CC256x would have pointed to the linux board quicker.

    Best Matthias