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/TM4C129XNCZAD: TM4C Energy Optimizations

Part Number: TM4C129XNCZAD
Other Parts Discussed in Thread: EK-TM4C1294XL, CC3100, TPS63020, BQ25892

Tool/software: TI-RTOS

Hi everyone,

I hope you are doing fine.

I am working on energy optimizations in a project and i am using different techniques to get the most out of instrument battery run time. I have tried and tested different MCU clock frequencies, between 30 MHz and 120 MHz, with external 25 MHz crystal oscillator while monitoring MCU current consumption. At lower frequencies, the MCU current consumption drops down fairly. Along with that, i am trying to save even more energy by checking the Ethernet cable connection, for Web server use, and if cable is not connected, i am powering off the Ethernet PHY. I must mention here that i am using TM4C integrated PHY. Every 5 seconds, my code powers ON the PHY and checks if cable is connected. If yes, it does not power OFF the PHY. However, there is one limitation here that i am observing. After powering ON the PHY, it takes about 1600 milli seconds for the connected cable to be detected, both at 30 MHz and at 120 MHz. This cable detection seems to have no relation with MCU clock frequency. Due to this 1600 milliseconds delay when PHY is in powered ON state, the consumed energy graph rises. Given below is the code that i am using for this purpose. Please have a look at i and also the questions i have listed below. Thanks in advanced to everyone who interacts with this post.

// Get emac PHY powered OFF status
emacPhyBmcr = EMACPHYRead(EMAC0_BASE, 0u, EPHY_BMCR);
// If emac PHY is powered OFF
if(emacPhyBmcr & EPHY_BMCR_PWRDWN)
{
// Power it ON
EMACPHYPowerOn(EMAC0_BASE, 0u);
GPIOPinWrite(GPIO_PORTQ_BASE, GPIO_PIN_4, GPIO_PIN_4);
SysCtlDelay(40000u*emacDelay);
GPIOPinWrite(GPIO_PORTQ_BASE, GPIO_PIN_4, 0);
}
// Wait while emac PHY is powered ON
while(EMACPHYRead(EMAC0_BASE, 0u,EPHY_BMCR) & EPHY_BMCR_PWRDWN)
{
}
// Get emac link status
emacIsLinkUp = EMACSnow_isLinkUp();
// Check if cable is connected
if(emacIsLinkUp == false)
{
// Power it ON
EMACPHYPowerOff(EMAC0_BASE, 0u);
}

I must also mention that i am using TI RTOS NDK for Ethernet client. In code given above, i am toggling PQ4 to measure the delay after which the connected cable is detected after PHY is powered ON from powered OFF state. Please have a look at questions listed below.

(i) Is there any step that i may be missing that will eliminate the 1600 ms delay for cable detection?

(ii) Will there be any loss to Ethernet PHY registers configuration due to this power ON power OFF cycle?

(iii) If anyone has worked on TM4C energy optimization, can you please share your experience?

Thanks,

Muhammad Shuaib

  • Hi Muhammad,
    The internal PHY is clock by the 25MHz MOSC which is independent of the SYSCLK.

    Please take a look at the below links where the time for PHY auto-negotiation is estimated. 1600ms doesn't seem unreasonable.

    www.ieee802.org/.../brown_1_0102.pdf
    www.tomshardware.com/.../19648-42-ethernet-auto-negotiate-time

    What if you keep the PHY on all the time but only turn off the MOSC ? What does the power look like compared to going through negotiation each time it is powered up?
  • Hi Charles,

    Thanks for taking the time to contribute to this post. The information you have provided is very helpful in progressing in right direction. Can you please let me know if this powering ON/OFF PHY will have any issues? Do we have any chance of PHY malfunctioning or any impact on MCU due to this?
    Another solution for energy optimization that we are considering is that every two seconds we put the MCU to sleep and also disable the Ethernet PHY in sleep mode along with other peripherals. Please share your expert opinion on this approach.

    Thanks,
    Muhammad Shuaib
  • Hi Muhammad,

     I don't see issues powering ON/OFF the PHY.  

     Reading the datasheet you could place the PHY in different power saving modes. I'm not sure in which mode the EMACPHYPowerOff() wil put the PHY into. Could you experiment with different power saving modes (i.e IEEE Power down or others) to see if you are getting different energy profile?

  • Hi Charles,

    I will look into it and see what can be done with PHY to save some power. Right now i am trying to configure my system, based on TM4C129XNCZAD, at 30 MHz to save some milli amps. As per the documentation, at 60 MHz, the MCU will consume about 76 ma, compared to 105 ma at 120 MHz. When i check the power consumption difference on EK-TM4C1294XL, the power drop at 30 MHz, as compared to 120 MHz is close to what is mentioned in documentation. However, when operating the MCU at lower frequencies, on my TM4C129XNCZAD system board, the power consumption difference is merely around 11 to 12 milli amps between 120 MHz and 30 MHz. Is there any configuration specific to TM4C129XNCZAD that i am missing?

    Thanks,
    Muhammad Shuaib
  • Hi Muhammad,
    How is your system board different compared to the launchpad? What did you measure on your system board at 120Mhz and 30Mhz? Do you have other boards that you can experiment with for current measurements? Can you also confirm that you indeed are running at 30MHz rather than some higher frequency? Normally the current consumption consists of two parts, the leakage current and dynamic current. The dynamic current is related to the frequency while the leakage is intrinsic to the transistors in the technology node the silicon was built upon. You should see a linear relationship on the dynamic current wrt frequency. The leakage will be highest when operating at the highest allowed temp and highest allowed voltage and the strongest silicon material.
  • Hi Charles,

    I have a custom board with peripherals (CC3100, LEDs, Buttons and some other modules). I measured the overall current consumption of system, both at 30 MHz and 120 MHz. Yes, i do have other boards and i have checked the current consumption at more than one boards, and got the same results. For confirming the 30 MHz system frequency, i configured the PWM module clock at 30 MHz using PWMClockSet(PWM0_BASE, PWM_SYSCLK_DIV_1), and configured PWM generator 0 at 6 MHz frequency, using formula given below.
    numberOfCycles = 30000000/6000000;
    PWMGenPeriodSet(PWM0_BASE, PWM_GEN_0, numberOfCycles);
    I monitored the PWM output signal on oscilloscope and confirmed the signal frequency to be 6 MHz. There is another point also that i want to mention here. Although, on EK-TM4C1294XL, i measured the MCU current consumption using the JP2 which is provided for this purpose i.e. measure the current consumption of MCU only, i also measured the overall current consumption of EK-TM4C1294XL from power supply and still saw a reasonable current consumption drop at 30 MHz, as compared to that at 120 MHz. However, as i do not have a point on my custom board where i can measure the current consumption of MCU only, i am measuring the overall current consumption of my board. But there is very small drop in overall current consumption at 30 MHz , as compared to that at 120 MHz while drop in overall current consumption of EK-TM4C1294XL at 30 MHz is quite significant. Having a target of energy optimization set at current consumption far below than what i have right now, changing the system clock is not resulting in saving sufficient power or at least close to what is mentioned in MCU documentation. If you have any comments or suggestions that could be helpful in this matter, please do let me know.

    Thanks,
    Muhammad Shuaib

  • Hi Muhammad,
    Is it possible that you can put the major components (i.e. CC3100 and others) on your system board into some type of deep sleep mode and keeping only the MCU active? You will then measure the current against the LaunchPad at different frequencies. In your LaunchPad measurement you have a drop of about 30mA from 120MHz to 60MHz. However, in your system board you mentioned you observe much less. I tend to think that the amount of drop from the MCU side was offset by the gain by other components in your system board.
  • Hi Charles,

    I will see if i can put the major components on my board into some low power mode and then check the current consumption over different frequencies. I just have a question regarding the current consumption point that you mentioned at the end. If components connected to my system board do have to consume a specific amount of current, they should be, irrespective of how much current MCU is consuming or saving at different frequencies. How is it that the components may start gaining the current dropped by MCU? If this is the case, it wont make any difference in power consumption no matter at what frequency we are running the MCU, or unless , at some point, the components are already consuming maximum current they require and then we see a drop in overall power consumption?

    Thanks,
    Muhammad Shuaib
  • Hi Muhammad,
    What I meant in my last reply was that if the launchpad was seeing 30mA drop but your system board was only seeing say 12mA drop then the other 18mA drop was likely due to the consumption from other components. I do agree that not matter how much other components are consuming the delta drop in the MCU should scale similarly as the launchpad.
  • Hi Charles,

    Thanks for the update.

    I have disabled all the components that i can on my system board. Some peripherals are powered via a switch(TPS63020) and i don't have the enable pin in my control. Instead, i have enabled the IC's power save mode so that when the current draw from it will be below 100 ma,  the IC will go into power save mode(This helps save a few milli amps). After above configuration, i modified my code to only initialize GPIOs, to make sure that the components on board are in low power mode, and put the code in an infinite while loop. Here is what happens to power consumption at 120 MHz and 30 MHz(in while loop).

    System current draw is about

    (i) 93 ma when running at 30 MHz.

    (ii) 101 ma when running at 120 MHz.

    One point that i think should be mentioned here is that my system is powered by 5-36v input range LTM8055 buck-boost regulator(currently powered by 12v power supply) which is configured for 12v output. This output is fed to BQ25892. The output from BQ25892 is provided to TPS63020 which supplies 3.0v to MCU. As far as the EK-TM4C1294XL is concerned, i was powering it using the Booster Pack 5v pins. Could it be that i am not seeing a current drop, with my system board, close enough to or in direct correlation with what i was observing with EK-TM4C1294XL, due to these multi stage power conversions or due to it being effected by the efficiency of these power regulators used in my system board?

    Thanks,

    Muhammad Shuaib

  • Pardon - I happen to have been in communication this morning w/Charles - thus know that he is "tied up" - his response is likely to be delayed.

    As firm/I have done similar "low power design work" (in our case - "sub-surface, autonomous marine vehicles") all of the "new facts" you've (just) mentioned (today, via your 10:17 post) register "heavily" in your overall power budget.

    When performing such comparative measurements - you must - at all times - strive for as much "board to board," "chip to chip," "power source to power source" consistency as possible.    The fact that your custom board differs (significantly) from the Eval Board - is likely to confound your findings as regards power consumption of the MCU, alone.   (i.e. too many "other" power consumers!)

    In our case (and others - where low energy use is demanded) it is vital that ALL components - wherever possible - provide the eased means to, "Shut-down" or otherwise greatly reduce their current demands.    Such is especially important for the various power feed/regulating components - and this (appears) confirmed by your most recent posting.

    A method we (and others) employ to "perform such power consumption tests" is to perform, "Partial board builds" - in which only a limited number of components are first placed (this across several boards of course - to avoid the curse of "single board anomaly") and current is then measured & recorded.     Later the "next wave" of components are added - and the measurement repeated.    In this manner - via the "isolation of components actively "in play" - reliable insights into the current demands of each/every component may be gleaned.

    The above represents "KISS" - steered into its "info discovery/enhancement" mode.     Isolation and limitation of the number of variables casts stronger data points than the "more massed" alternatives...

  • Hi Muhammad,
    Looks like there are quite some differences between the LaunchPad and your system board. As suggested by cb1, it is hard to compare the two. The efficiency of your various stages of the regulators and the amount of loads and switching activities (C * dv/dt) on the I/Os between the two different boards will also affect the current consumption of each.
  • Hi Charles, cb1_mobile,

    After my last comments on this post, I figured out that while i was testing the current consumption on my TIVA kit , which is powered by 5v supply, i was expecting the similar current drop with my custom board, which i was powering by 12v supply. I ran the numbers and came to know that at lower frequencies, the overall power consumption drop is quite close to what i was seeing with TIVA kit. The problem was that the current drop with 12v supply cannot be equal to current drop with 5v supply.

    Thanks to you guys for all the help in this mater.

    Proceeding with energy optimization, i am now trying to implement the hibernation mode with my custom board. I tested the hibernation mode on my Tiva kit(EK-TM4C129XNCZAD) and got it to wake, using GPIO , wake pin and tamper pins. Everything works fine with my Tiva kit. As we have two revisions of our custom boards here, with rev2 I tried the hibernation mode test and found out that the MCU goes into hibernation but immediately wakes up showing XOSC failure tamper event. With rev1  boards, i got the MCU to go into hibernation but it immediately woke up on configured tamper pin signal. I must mention here that on rev1 boards, we are not using the tamper pins so the pin that i configured for tamper signal is not connected to anything. I understand that may be the reason the MCU woke up from hibernation. But after this very first hibernation and wake up cycle, now i am unable to put the MCU into hibernation anymore. I debugged my code and saw that HIB_CTL_HIBREQ bit is not being set and code gets stuck in infinite while loop that i have placed right after call to HibernateRequest() function.

    Can you please suggest what could i be missing that my code works fine with Tiva kit but is not working with my rev1 board? Also, what can be the reason i am getting XOSC failure tamper event rev2 boards? Is there any configuration option that i can use to disable this tamper event?

    Thanks,

    Muhammad Shuaib

  • Hi,
    Is it the identical code you run on TivaWare and rev1 and rev2? If it is the same code and work on Tiva but your custom board then the investigation may need to be put on your hardware.

    Did you enable the tamper feature in the code even if the tamper pin is not connected? Please note that each tamper IO has a weak pull-up according to the datasheet.
  • Charles Tsai said:
    ... your custom board then the investigation may need to be put on your hardware.

    It should be asked if "Any HW circuit differences - at all - exist w/in your custom board(s) and the "working" EVM?"    (especially at/around the hibernate/tamper circuit fixturing)

    You note that "tamper" is not connected - yet it proves (always) wise to provide some (minimal) trace routing - ending in a via - so that the pin may be terminated.    Again - your treatment of "tamper" must duplicate what's been done on the EVM.

    You've mentioned multiple, cascaded power supplies - might these "impede" your entry into "hibernation" - and/or your "escape" from it?     Your introduction of the same 5V supply (employed w/'your EVM) may enable your discovery of (any) impact of your power supplies upon "hibernate" and/or "tamper".,,

  • Hi,

    Regarding the issue that i was facing earlier, that my  instrument was not going into hibernation, I guess the reason behind it was that i was using TI RTOS based code and i was putting the MCU to to hibernation in main(). For the very first time, it would go into hibernation, but second time it wont. When i implemented the code in my Shtudown task, which runs after BIOS_start. After this change, i was able to get my rev1 into hibernation and wake it up on tamper signal generated by PM4 pin. However, when i try the same code on my rev2 board, the board goes into hibernation and immediately wakes up reporting XOSC failure tamper event. We checked the clock signal on both our boards and it is working fine. Is there specific reason behind this XOSC failure event? Also, is there any way to disable this XOSC failure/tamper event?

    Thanks,

    Muhammad Shuaib

  • As you address this most recent post to me - I'll respond as best I'm able.      As neither firm nor I use (or like) your "129 class" MCU - "129" specifics must be handled by others.

    Your post details the apparent "proper working" of "Rev1" - yet "hibernation/tamper" issues appear upon "Rev2."     Would it not make great sense for you to thus, "carefully/methodically review any/all "differences" between Rev1 & Rev2?"    Insure that the software - installed w/in each Rev - is absolutely identical.

    Unstated is the "number of Rev2 boards" which evidence this issue.    Single board anomalies "eat" time/effort - usually unwarranted.    Your test of multiple Rev2 boards - and reportage - would strengthen the interest of your helper crüe...

    Your newest writing does not reveal, "How or (even) If" you've "removed the cascade of power supplies" from your newest set-ups/tests.    (such was past suggested)     The "more variables" you enable (introduce) - the harder & longer the job of detecting & resolving (all) issues...

  • Hi cb1_mobile,

    Thanks for taking the time to reply to this post.

    I have reviewed the hardware changes for rev2 boards and there are not any that may contribute to the this issue that i am facing. We have only changed some pins for on board peripherals. There is not any change related to hibernation. We are using the same crystal that we used in our rev1 boards.

    I have checked hibernation mode with three rev2 boards and all three are exhibiting same behavior i.e immediately wake up from hibernation upon XOSC failure event.

    Regarding the power regulators, it is not possible to physically remove or disconnect these components on board because we do not have tools required to do changes with BGA components on a multi layered PCB.

    Thanks,

    Muhammad Shuaib

  • Hi Charles,

    Sorry for replying late to your queries.

    I have developed code that works on TIVA kit and rev1 board but i am having issues with the code as it does not work properly on rev2 boards. On my rev2  boards, the instrument goes into hibernation but immediately wakes up upon XOSC failure. I am looking into my hardware and also code to see if anything specific is causing this issue. If you have any suggestions on this issue, please do let me know. Also, is there any way to disable this XOSC tamper event from waking the MCU?

    Thanks,

    Muhammad Shuaib

  • Hi Muhammad,
    If you select the external 32kHz XOSC for hibernate clock then once the tamper feature is enabled, the XOSC fail detect logic is enabled. You can try to use the internal HIB LFIOSC as the source for hibernate mode to see if it makes a difference.