CC1312R: TI 15.4 + Sensor Controller - Reduce current

Part Number: CC1312R
Other Parts Discussed in Thread: ENERGYTRACE, SYSCONFIG

Hello,

I checked out the current consumption of my project using EnergyTrace and saw that the minimum current it was consuming was approx. 6 mA. For this reason I decided to compare the project with the example project and saw that it was able to reach a minimum current of around 1-2 mA, in contrary to my project..

The changes between the example project and my project are not a lot. I included a Sensor Controller project. After the reporting time ends, the execution task is manually executed and a semaphore is used to put the task in an "Idle" state. After further digging I found out that defining the pins caused the current to increase by some mA. I confirmed this by adding the sysconfig of my project to the example project. I have removed the pins from Sysconfig, but they are defined in the Sensor Controller project too, so the current will go to ~6 mA whenever the main communicates with the Sensor Controller and then stays on at least 6 mA.

I have added links to the power profiles because the pictures resize when I paste them in here directly. The first one is my project, the second the example project. For the context: I've merely let the devices start without a collector around and they do not contain any join information. 

My own project:
https://imgur.com/henIqiM 

Example project:
https://imgur.com/TXocBKI

Now that the context is clear, how to ensure that the main is in standby mode? Is it possible to completely disable these pins after the execution is done, and re-enable them when needed? Right now it looks like the standby mode is being blocked by the sensor controller

I would really appreciate the help.

Kind regards

  • First of all, are you running the code on your custom HW or on our LPs?

    Either way, I would strongly recommend that you start with one of the really simple examples, for example the pinStandby examples, and verify that the current consumption is as expected. When running the pinStandby example on our LP, you will see mean current consumption of 0.001 mA:

    Once everything is expected here, you can add your SC code. It is not necessary to config the pins used by the sensor controller in sysConfig. This is done in SCS.

    BR

    Siri

  • Hi Siri, thanks for your response. I am running the code on a LaunchPad.

    I will look into the example.

  • The pinStandby project does consume as expected.

    I see that the current increases due to initializing the Sensor Controller. Even after stopping the task, the current consumption stays high. But when I uninitialize the Sensor Controller, the current decreases. Is this a correct execution flow? That the Sensor Controller will be reinitialized after each measurement request? I would expect that stopping the task would be enough.

  • I would assume that the increased current consumption is related to the state of the GPIOs that is used by the sensor controller code. That is, if you set an output high from the sensor controller task to turn on a LED, the LED will still be on after the sensor controller task is done, so the additional current draw from driving the LED will still be present.

    If we should look into this some more, you need to share a simple demo code (the sensor controller code, and how it is called from the main application) so that we can reproduce the behavior here on a LP, and see if this is as expected or not.

    You should use one of our Standard code examples (for example the pinStandby) and then provide the modifications we need to do to this code example, together with the SCS code.

    BR

    Siri

  • I have made a demo project where the pin configurations that I use for my actual project are used. I have only added a demo snippet where the driver is initialized from the beginning as I found the problem to be there.

    I couldn't insert the SCS project so I am sharing a pastebin link: 

    The modifications that ought to be done in the pinStandby.c, are:

    scifOsalInit();
    scifInit(&scifDemoDriverSetup); // Initialize Sensor Controller -> Commenting this seems to reduce current

    Below line 74: hPin = PIN_open(&pinState, LedPinTable);

    Files that need to be included, are:

    scif_demo.h
    scif_framework.h
    scif_osal_tirtos.h

    This is the result I found when I executed the demo:



    Thanks for your time by the way!

    Kind regards,

    Mohamed

    EDIT: I totally forgot to let you know that, for the context, the pin configuration is based on a custom board I will be receiving soon. Due to time constraints I cannot wait for this board, thus I am testing the code using a LP.

  • I cannot access the files you shared. Can you please just make screenshots of your pin configuration etc. from SCS and insert the code I need to insert. Then I can try to recreate it.

    Just a comment. What are the pins that you are using in the SCS used for on the LP?

    Siri

  • Hi Siri, of course. See the details below. Regarding the comment; I am not using those pins on the LP anymore. I've removed them from my sysconfig.

    CCS:

    Paste the following in pinstandby example project;

    Below line 74: hPin = PIN_open(&pinState, LedPinTable);

    scifOsalInit();
    scifInit(&scifDemoDriverSetup); // Initialize Sensor Controller -> Commenting this seems to reduce current

    Included files:

    scif_demo.h
    scif_framework.h
    scif_osal_tirtos.h

    SCS:

    Settings

    Pin Configuration

    Pin Mapping

    No code is needed in SCS to reproduce it. Merely the configuration. This is the result I had

  • I have not made a project with your setup, but from what I can see you are using several GPIOs that are connected to different HW on the LP, and I would assume that this is what causes your high current consumption. If you for example select a GPIO to be an output and it is connected to an output on one of the peripherals on the LP, you would see high current consumption.

    When testing on the LP, you need to select the LP you have under "I/O mapping", and only use the proper I/O.

    By addidng one and one GPIO, it should be fairly easy to see what I/Os causes the high current.