• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 399 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.

CC1125: CC1125 excess power consumption when oscillator is off?

Eric Nees
Prodigy 105 points
Part Number: CC1125
Other Parts Discussed in Thread: ENERGYTRACE, MSP430FR2355

Ok, I have a CC1125 on a custom PCB based on swrr107a.  It uses a 40Mhz crystal; EXT_OSC is tied to ground.  It's connected via SPI to an MSP430FR dev board.  I've based my code on the "easy link tx" code and configured the registers appropriately using SmartRF.  Transmitting works as expected and I can receive data reliably on another device. Power consumption in TX, RX, IDLE as measured via energy-trace is as expected.

The problem comes when I issue the SPWD strobe.  As soon as that strobe is sent, power consumption rises to 40 or even 80mW which is even higher than during transmit!  If I pull CS low again after that, the chip returns to IDLE and power consumption drops back to normal levels.  On a whim, I tried the SXOFF strobe and noticed that it had the same effect of increasing power consumption.  So I set XOSC_CORE_PD_OVERRIDE to 1 (to force the crystal on) and then tried SPWD again.  In this configuration I do not observe the excess power consumption, but it's obviously not as low as it would be if the XOSC was off.  It seems that shutting down the crystal is causing excessive power consumption.  I'm not talking about a couple uA... I'm seeing >20mA.

What is happening here?  I've seen at least one other post here with the same problem, but that one was unresolved.  Let me know what you want to see and I'll post it.

  • 0
    Prodigy 105 points

    This is what I'm seeing.

  • 0
    TI__Guru* 81531 points

    Hi Eric,

    Is this the collected power consumption for CC1125 + MSP430?

    Can you tell me what software version is running on CC1125?

  • 0 in reply to Marie H
    TI__Guru**** 317180 points

    More or less all the cases I have seen with excess current consumption after a SPWD strobe is due to an undefined input pin on the MCU side. Ensure that SO has a defined state in SLEEP to ensure that you don't have any floating pins. 

  • 0 in reply to Marie H
    Prodigy 105 points

    Correct, that EnergyTrace is for the whole system.  With the CC1125 removed and the MSP sleeping in LPM3, I see <1uW.

    I'm not sure what you mean by software version.  The CC1125 identifies itself as hardware version 0x23.

  • 0 in reply to TER
    Prodigy 105 points

    I have the internal pullup on the uC enabled on the SO line.  My CC1125 GPIO configs are as follows:

        {CC112X_IOCFG3,            0x33},
        {CC112X_IOCFG2,            0x33},
        {CC112X_IOCFG1,            0x30},
        {CC112X_IOCFG0,            0x33},

    I've tried 0xB0 as well, with no change.  I've modified my code to be very simple and not require any GPIO interrupts.  I'm polling the status of the chip every few ms after TX to verify that it's in idle before I issue SPWD.  I also tried just cycling between idle and sleep once per second, without ever going to TX/RX and still see the same results with high current consumption in sleep.

    With the CC1125 removed from the circuit and the MSP sleeping in LPM3, I measure <1uW so I think the uC pin configs are OK.  In any case, 10-15mA seems like way too much to be caused by a floating pin.

  • 0 in reply to Eric Nees
    TI__Guru**** 317180 points

    - Could you confirm with a plot of the SPI interface that the last thing that happens on the SPI interface is the SPWD strobe before sleep? Since toggling the CSn pin will wake up the chip nothing else has to happen on the bus. 

    - I'm not familiar with the MSP. Have you verified that the pull-up is used in LPM3? Test setting GPIO1 to something else than high-z, hw0 should be good.  

    - Are you using a polling based system? 

  • 0 in reply to TER
    Prodigy 105 points

    I've been very careful to control that CS line for exactly the reason you suggest.  I've tried a few variations of code that use blocking delays or entering LMP0/1/3 immediately after the strobe but the effect is always the same.  I have also tested purposefully pulling CS low at some time after the strobe, in which case the CC1125 returns to idle as expected (my above energy-trace plot shows one example of this).  I will post a screenshot of the SPI later today.

    I'm using an MSP430FR2355.  I've tried pull up and pull down on SO line, and both work in active more and LPM3.  The CC1125 behaves the same in all cases.  I will try setting GPIO1 to hw0 as you suggest.

    Yes I'm polling the chip status using a SNOP strobe.  The only time I do this is prior to issuing the SPWD strobe, in order to verify that the CC1125 is in idle. I have good confidence that the polling works because I can observe the 1125's state as it transitions through TX and into IDLE etc as expected.

  • 0
    Prodigy 105 points

    Alright, I resolved this one.  It was a hardware design error the whole time.  The symptoms should have made that obvious, in hindsight.

    The CC1125 has a pin "DCPL_XOSC" (pin 29) for "external decoupling of XOSC supply regulator."  The schematic in swrr107b shows all the parts for two different oscillator configurations: a crystal and an external oscilator.  My layout is configured for the crystal, X1.  I mistakenly assumed pin 29 was an input and connected it to Vdd.  In reality pin 29 is an output, R321 and R322 are DNP, and pin 29 shouldn't be connected to anything except C291.  It's shown correctly on page 28 of the datasheet as well, in a simplified view.  It seems that pin 29 is powered down during XOFF, leading to basiclly a short circuit in my case.  This explains why forcing the oscillator on eliminated the extra current consumption.

    With that corrected, system power consumption is now where is should be, down around 1uW according to Energy Trace.