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

Original question:

CC1352R: CC1352R Low Power Mode

CC1352R: Low Power Mode with SCS

spanky
Expert 2710 points
Part Number: CC1352R

I'm having a rough time figuring out how to get the cc1312 into low power mode. I'm finally narrowed it down to the SCS code apparently not shutting down completely. I have all the settings I can find in SCS to low power, 2MHz, uninitialized states, etc.

The SCS code runs for about 30s (it enables an output and does some SPI transfers). Then I uninitialized it for another 30s (which is where I expect to see low power mode) and repeat.

Prior to the first SCS initialization, I sleep for 5 seconds just to verify it is in low power mode (i.e. microamps and below the capacity of my ampmeter). Once the SCS code starts, the whole thing runs around 0.75mA and stays there while the SCS is running or not.

The problem is that when I am done with the SCS, it does not drop back into low power mode.

To "end" the SCS, I do the following:

    while(scifWaitOnNbl(0) != SCIF_SUCCESS);
    while(scifStopTasksNbl(BV(SCIF_SENSOR_DATA_OBJECT_TASK_ID)) != SCIF_SUCCESS);
    scifStopRtcTicks();
    scifUninit();

But that doesn't appear to be enough and it continues to run at the higher current (when it should drop significantly following that code above).

Any thoughts?

  • 0
    TI__Guru 58425 points

    Hi Spanky,

    Could you share the SCS project or code you are using? By the description you give me, it sounds like you should be fine with simply having a "one shot" task that you run every 30s (no need to Uninit the SC). You would however make sure to disable peripherals that the SC uses as the end of the task to avoid excess power consumption. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 2710 points

    I'm not sure about sharing the project, but it is mostly straightforward. I have 2 sensors that I am powering from GPIO's. I previously had an issue with improper wiring that caused a current drain, but I'm pretty sure that is resolved. Both sensors use SPI.

    The CCS project powers up the sensors via gpioSetOutput() in the initialization code, and then in the termination code, they are powered down via gpioClearOutput()

    The only thing I found to deal with shutting down the SPI lines was spiClearMosi(). My suspicion is the CS lines are drawn high, but I am not doing anything explicitly to lower those at the end of the cycle (nor can I find anything in the CCS SPI docs that indicate how to do that).

    Should I treat the SPI lines like GPIO's at the end and gpioClearOutput() on all of them? Their un-initialized states are configurable, and that is why I explicitly was uninit'ing the CCS

  • 0 in reply to spanky
    TI__Guru 58425 points

    Hi Spanky,

    It is really hard to say without having the code but how have you configured the MISO line, you are free to select if this is no-pull, pull-up or pull-down. This is not configured in a way that causes current leak (see note in help section):

    It is assumed that the SPI signals are not shared with another, external SPI master. The SCLK and MOSI lines are driven while CSN is deasserted to prevent these lines from floating. The MISO line can be configured as no pull, pull-up or pull-down. Note that the MISO input buffer is disabled while CSN is deasserted, and will not cause leakage if the pin is left floating in this state (with no pull). 

    If you are not OK with sharing the project here, feel free to send me a private DM if that could work for you!

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 2710 points

    My concern is the idle period when the SCS code and sensor power should be off.

    If I simply comment out the kickoff to the SCS (i.e. I never start the SCS in the first place), the power draw remains low. I have a radio transmission once a minute and still see that spike occurring. I should be able to return to this low power state for the ~30s when I am not using the SCS or sensors.

    Following the end of the SCS block, I am now explicitly opening and closing all the pins in my main task to ensure they are in a good state (still haven't figured out how to do this "cleanup" in SCS). That did a tiny bit as it previously drew more during the idle periods, I'm guessing because the CS lines were still high following the shutdown of the SCS code? But, even still this power draw is still substantially higher during the idle periods compared to when I test it without the SCS code even running in the first place.

    I also tried clearing out my SCS project (not using any of the GPIO), but that still resulted in a high power draw during idle periods.

  • 0 in reply to spanky
    Expert 2710 points

    Ooops, another clue. I went back and cleared out the SCS code. So it basically does nothing but fire off some callbacks to the main thread that otherwise would have the sensor data.

    When I startup the whole program I sleep() for 5 seconds, just to get a handle on the power usage.

    Under the above scenario, the power is low during the first 5 seconds, low during the periods of SCS, and then mysteriously high during times where the SCS is supposed to be off.

    The tasks are blocked on event loops during this period waiting for a timer to trigger the whole cycle over again. I've verified that the power is low in this period if I never start the SCS.

  • 0 in reply to spanky
    Expert 2710 points

    Arrrrrgh, this is driving me bonkers... I thought about your comment "no need to Uninit the SC" and so I commented out the scifUninit(); call after a SC cycle. That bought me a drop in current where I expected it, which seems like progress... but only after the first cycle? Then its back to a consistent (higher) current draw whether the SC is running or not for subsequent SC cycles.

    Also, I moved my scifInit(&scifDriverSetup); call to when the program first starts up (rather than on each SC cycle), so its not getting reinitialized.

  • 0 in reply to spanky
    Expert 2710 points

    Ok, I have a bunch more info. Not calling scifUninit(); gives "mostly" the desired result. I'm not sure why that is.

    Unfortunately, it also appears that some current is still leaking through one of my sensors, and my best guess is over the CS line. The sensor is a BMP280 (which from previous experiences, is very leaky if there is power on any of the SPI pins while powered down).

    I think I can focus the question here to the CS pin, which appears to have 2v while the SC is supposed to be off (and VDD/VDDIO on the sensor are also off). How to I ensure the CS pin is drawn low after the SC is stopped?

  • 0 in reply to spanky
    TI__Guru 58425 points

    Hi Spanky,

    I have not had time to look into the code yet but regarding the leaking over CS, the CS pin should still be able to be controlled as a normal GPIO in SCS.

    What I mean by this is that following the spiEnd() call, you can then write the CS pin low yourself after you have shut down the sensor just like if would have been a normal IO. Could you try this out and see if it solves it for you?

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 2710 points

    So like this?:

    gpioClearOutput(AUXIO_SPI_CSN_SENSOR);

    I tried setting the pin in the main task (outside of SCS), but I am having trouble understanding how pins are shared between the SC and the main processor (and I guess also in SCS by itself... it appears sharing pins is valid). I haven't tried this since I started measuring voltage on the various pins, so I will give that a shot later today.

  • 0 in reply to spanky
    TI__Guru 58425 points

    Something along those lines yes.

    Sharing pins between the SC and main CPU is possible but not trivial. I would advice against it when possible as it could be source of headache. If you can't get this working then I would assume you might need to go with the "un-init" solution. In this case you would also need to initialize the IOs again on the MCU side to put the sensor in the correct state following the un-init of the SC.