TMS320F28069: TMS320F28069

Pandurang,

Using the CAN, or any peripheral to wake the device in LPM is only possible when using IDLE mode.

There are a few avenues you may take to further reduce the power consumption. Have you disabled other peripheral clocks? Also, as CAN is running at a maximum of 1MHz, you do have the ability to lower your system clock before entering IDLE. Once the CAN ISR has begun executing, you may resume full speed operation.


Thanks,
Mark

Hi,

Yes. I have disabled the clocks of other peripherals and now the current is @40mA. The system is operating on battery and need to reduce the current so that battery life can increase. Hence we need to use the STANDBY or HALT mode. Is there any way by which we can wakeup the controller? I know GPIOA port can wakeup the controller but we need to wakeup using CAN message?

Thanks,
Pandurang Khutal

Hi,

We have used GPIO30 pin to wake up the controller from HALT mode. The code snippet is below. Now the controller wakeup is happening by using CAN message in all modes. I have transmitted the CAN messages from PCAN to wakeup the controller. But the current drawn in IDLE , STANDBY and HALT mode is same. Can you please suggest what is the wrong in below code?

We have also disabled the clocks of peripherals. The requirement is to further lower down the current, so trying to put the device into STANDBY or HALT mode.

Sleep Mode Operational current Sleep Mode Current
IDLE 130mA 60mA
STANDBY 130mA 60mA
HALT 130mA 60mA


//This function getting called upon any request came to put device into sleep mode. before this function all clocks are disabled
void enter_lpm(void)
{
DINT;

EALLOW;
//Do not enter HALT low power mode when the device is operating in limp mode (PLLSTS[MCLKSTS] = 1).
//Only enter low power mode when PLL is not in limp mode.
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 1)
{
//SysCtrlRegs.LPMCR0.bit.LPM = 0x0000; // LPM mode = Idle
// SysCtrlRegs.LPMCR0.bit.LPM = 0x0001; // LPM mode = Standby
SysCtrlRegs.LPMCR0.bit.LPM = 0x2; // LPM mode = Halt
}

//Select wakeup source
GPIO_lpmSelect(hal.gpioHandle,GPIO_Number_30);
EDIS;

EnterIntoLMPModes();
}




#pragma CODE_SECTION(EnterIntoLMPModes, "ramfuncs");
void EnterIntoLMPModes(void)
{
EALLOW;
/* Put Flash to lowest Power */
FlashRegs.FPWR.bit.PWR = 0;
/* Disable XCLKOUT */
SysCtrlRegs.XCLK.bit.XCLKOUTDIV = 3;
EDIS;

//Force a pipeline flush to ensure that the write to
//the last register configured occurs before returning.

__asm(" RPT #7 || NOP");

/* Execute IDLE command to wake up on CAN */
//
IDLE;
}


//This is in cmd file for loading ramfuncs
ramfuncs : LOAD = FLASHG // YJL to accommodate the bootloader
RUN = RAML1, // RAML0_L1 to avoid any conflict with the CAN bootloader
LOAD_START(_RamfuncsLoadStart),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart),
LOAD_SIZE(_RamfuncsLoadSize),
PAGE = 0

Thanks,
Pandurang Khutal

Pandurang,

            Looking at your current numbers, it doesn’t appear you are entering the low-power mode at all.

 

Some bits/registers pertaining to LPM are EALLOW protected. It is conceivable that EALLOW has been inadvertently turned off elsewhere in the code. Until your debug is complete, please comment all EDIS instructions.

 

With the debugger connected, check if LPMCR0 register is written with the correct value before you execute the IDLE instruction. In fact, you should step through the code with the debugger connected to ensure that the code is working the way it should. For example, does it actually jump to RAM to execute the flash power-down function and IDLE instruction?

 

Please run the Example_2806xHaltWake project in C2000ware "as is" and see what current numbers you get. If you use that code as a reference, you should be able to easily figure out what is wrong with your code. It will also tell you the numbers to expect on your own hardware. Also, does your hardware have the provision to measure the current that only goes into your MCU? In other words, could the current you are measuring be going to some other components on the board as well?

 

If you are using a series resistor for current measurement (to leverage Ohm's law), be very careful with the value you choose. It would be tempting to choose a high-value resistor to get a measurable voltage-drop (since the HALT mode currents are in the uA realm). However, such a resistor could also "current-starve" the core during power-up and put the device in an undefined state. Considering your current numbers are the same across all 3 LPMs, I suspect this is what is happening. It is likely your code is not getting executed at all. This is the reason I want you to step through your code with the debugger connected.

 

No need to disable peripheral clocks in STANDBY or HALT mode through code. That is done automatically in the design.

Please read this post carefully. It has some good information and tips that could help you: e2e.ti.com/.../577005

Hi Hareesh,

Thanks for the update.

We have not used the resister to measured the current. The current is measured using the multimeter/power supply current display.

We have debug the above code and found that code is entering into RAM area and clearing the flash power bit. See the below code. Our observation is that it is not going to IDLE line before this the debugger is popup the error. This error is not getting in IDLE sleep mode.

Can't Single Step Target Program:
(Error -1156 @ 0x8856)
Device may be operating in low-power mode. Do you want to bring it out of this mode? Choose 'Yes' to force the device to wake up and retry the operation. Choose 'No' to retry the operation without waking the device.
(Emulation package 7.0.48.0)

So we thinking that code is not executing IDEL model command hence not entering into HALT mode. Can you please suggest what is the wrong with above code?

#pragma CODE_SECTION(EnterIntoLMPModes, "ramfuncs");
void EnterIntoLMPModes(void)
{
EALLOW;
/* Put Flash to lowest Power */
FlashRegs.FPWR.bit.PWR = 0;
/* Disable XCLKOUT */
SysCtrlRegs.XCLK.bit.XCLKOUTDIV = 3;
EDIS;
//Force a pipeline flush to ensure that the write to
//the last register configured occurs before returning.
__asm(" RPT #7 || NOP");
/* Execute IDLE command to wake up on CAN */
//
IDLE;
}

Thanks.
Pandurang

You get that error only after the successful execution of the IDLE instruction.

 

Did you follow my suggestion to run the example code from C2000ware? This step is very important.

 

Not a good idea to rely on the display in the power supply when your current is in the uA realm. Please use a bench-top mulimeter that has good accuracy in the uA realm.

Hi Hareesh,

As per your suggestion I have used the multimeter and measured the current in all three modes. these currents are below.

IDLE sleep mode current 40mA

STANDBY sleep mode current 29mA

HALT sleep mode current 26mA

By running the LMP code from RAM I able to put the device into HALT mode but it is not wakeup on can message. Can you please check with above code what is crating an issue?

I checked in STANDBY mode the device is wokeup on CAN message properly and same logic I used for HALT mode to wakeup but it is not waking up.

Thanks,

Pandurang Khutal

Pandurang,

 

Your HALT mode current of 26mA does not look correct. Either the device is not in HALT mode or your meter reading is incorrect. Is this with the example code from C2000ware? Please confirm this. As stated before, measuring currents in the uA realm is very tricky. If the meter doesn’t have sufficient resolution/accuracy, you could get an erroneous reading. Bear in mind that you get the best accuracy in the lowest possible range. When you start your code, you are in the "operational" mode of the MCU, where 100mA range is appropriate, but in HALT mode, 10mA range is appropriate. Again, when you wake up from HALT mode, you are back in operational mode. The meter you are using should have excellent auto-ranging capabilities to switch the ranges seamlessly without interrupting power to (or current-starving) the MCU. We use a 6 1/2 digit multimeter in the lab. What is the make/model number of the multimeter you are using?

 

How do you ensure you are only measuring current going into the MCU? Which rail (Vdd or Vddio) are we talking about? Do you use the on-chip VREG?

 

Conduct your "HALT mode wakeup using CAN" tests without connecting any multimeter. Once you get this flow working, bring the multimeter into the experiment.

 

Have you ensured that the minimum pulse-width requirements for the HALT-mode wakeup signal (as shown in the datasheet) has been met? Could you provide a scope capture of the wakeup signal?

 

What is the CAN bit-rate?

 

What clock source are you using?

 

Could you share the schematics of your board with me privately?

 

To summarize, this is the debug sequence I would like you to follow:

1. Run the example code from C2000ware, without the multimeter. No need to even wakeup the device. The objective is to simply determine if the device goes into HALT. Do not disable the XCLKOUT output. If the device goes into HALT, XCLKOUT will vanish automatically.
2. If #1 is successful, bring the multimeter in and see if the current numbers you see are in line with what is mentioned in the datasheet.
3. If #2 is successful, try wakeup from CAN bus. Please read section 1.4.3 of the device TRM carefully to understand the differences between STANDBY and HALT modes.

Hi Hareesh,

I have tried with the example code from C2000ware and the current which takes is @26mA is the same. For measuring the current we are using TENMA 72-7720 multimeter.

We have not used the on chip VREG. We are measuring the overall current of the board  not the Vdd and  Vddio.

For wakeup we tried without having the multimeter in series with the supply which goes to the board but still the controller is not wakeup. The CAN bit rate is 250KBPS. We are using the external OSC as the clock source with PLL enable and core frequency is 90MHz.

As per the datasheet XCLKOUT output is disabled by default in HALT mode. In the standby mode controller is wakeup properly.

One observation is that, we are using the CAN transceiver from TI-CAN1042HVDRQ1 and it has the standby pin as a control pin. What is the status of the pins once controller enters into HALT mode. The pins status will maintain or it will goes to tristate?

The board which we have now do not have the provision to monitor the Vdd and  Vddio cureent directly. The supply which goes to the board is 12V and from that using LDO we have generated the 3.3V which goes to the microcontroller. We are measuring the current by putting the multimeter is series with 12V power supply.

The issue is the controller is not wakeup in HALT mode by using CAN message. But with the same logic the controller is wakeup in standby mode. Please suggest.

Thanks,

Pandurang Khutal

Pandurang,

If you are measuring the current consumption of the board, how are you certain that the MCU is the culprit. 26mA at 12V is 312mW!! This is especially interesting that you are measuring the same 26mA using the c2000ware example as your application code. This tells me that you have 312mW somewhere on the board that is not the F2806x.

The device pins will hold their state while in HALT mode.

1. Do you have the ability to monitor any GPIOs for debug purposes? You can set /clear GPIOs at certain events to ensure that your code is executing as expected. place one right before the IDLE instruction is executed. place another in the wake ISR.
2. If you have the ability to monitor the XCLKOUT pin, you can view if the device is entering HALT mode. this will be confirmed if XCLKOUT halts and restarts.
3. If you can observe the external XTAL as well, we can verify that when the wake pulse is held long enough for the XTAL to start back up again before it is released. at 250KHz CAN bitrate 4us pulses *should* be long enough for the XTAL to start, but only you can confirm that as it is application/board specific.

Thanks,
Mark

Pandurang,

            As already mentioned, you need to use a bench-top multimeter with 6 1/2 digits for HALT mode currents.

 

You should not measure the overall current of the board for HALT. You must measure only the current going into VDD and VDDIO rails. It is likely other components on the board are contributing to this 26 mA, as Mark mentioned. If you have a series ferrite bead for the MCU rails, you could remove them and insert the multimeter there at that point.

 

Regarding the transceiver, the GPIO pins indeed keep their state in HALT. For wakeup, did you measure the pulse width at CANRX pin?

Hi Hareesh,

As per the our discussion, we have modified the code and tested on the board but still we are not able to wakup the controller from HALT mode via CAN message.

I did change for wake source instead of wakeup on CAN message i used the GPIO pin 27 as wakeup source and it is wakup properly from HALT mode.

Can you please suggest why it is not wakeup from CAN message?

Thanks,

Pandurang Khutal