TMS320X28335 HALT mode versus datasheet current consumption

I'm not sure if it matters, but I am using a TMX part.

Matt,

    Exactly at what point do you measure the current? If the flash is indeed shut down and all I/O pins are unconnected (and their pull-ups are enabled), you should indeed see the datasheet numbers. There are no convenient hooks on the Controlcard to measure currents, unfortunately. Do you account for the losses in TPS62400? Did you remove U3? How about any curren draw in the "docking station" (the mother board)?

HareeshJ,

Using a slightly modified test program from TI, I measure essentially the same current to the core supply Vdd1.8, 2.58mA.  The program is appended at the end of this post.  The only modification is the header file change from 280x to 2833x

I have removed chip inductors L11,L12,L13,L14,L15,L16 and tied all of the DSP-side pins together.  I then placed a 1-Ohm 1% resistor on the pad for L11.  I am measuring the voltage drop across the resistor with a FLUKE 189 Multimeter, with specified accuracy of 0.025%.

I have also inserted a 1-Ohm 1% resistor in series with the 5V supply to the ControlCard28335.  There are no other connections to the 5V rail other than the ControlCard28335.  The total current drawn by the ControlCard28335 5V supply is 13.4mA.  U4, the uart opto-isolator, has been removed from the PCB, and R13 replaced with a 1-Ohm resistor.  R13 consistently measures 0.394mV, corresponding to ~0.4mA, which is consistent with the 0.3mA->1.0mA specified draw for the UART charge pump device.

The mother board does have connections to 18 pins.  My understanding is that these should not affect the current draw from the Vdd1.8 rail.

Ten pins are PORTA IO pins driving FET driver ICs.  These pins have a specified leakage of 1uA over temperature.  Further, the PCB trace connecting the FET drivers to the ControlCard have testpoints at a distance varying from 1.0 to 1.1 inches from the connection to the FET driver input pin.  The trace width is 6mil, weighting 1ounce, yielding a theoretical trace width of 60milliOhm.  This is confirmed with a multimeter.  The largest reading is 20uV, suggesting a worst-case leakage of 330uA per pin or 3.3mA for all pins. 

The other 8 are ADC inputs connected to the outputs of unpowered OPA4350 buffers.  I measure no more than 12.5uV (the repeatable limit of the multiumeter) across any element of resistor packs RN1 and RN2, removing those pins as a source of leakage.

Matt Mahin

/*********************************************************************
* Filename: HALT.c                                              
*                                                                   
Simple code meant to run off SARAM
*********************************************************************/


//#include "DSP280x_Device.h"     // DSP280x Headerfile Include File
#include "DSP2833x_Device.h"     // DSP2833x Headerfile Include File

void flash_sleep(void);

void main(void)
{

asm("  EALLOW");

/* Disable Watchdog  */
 
    SysCtrlRegs.WDCR = 0x006F;   

/* Enable all pull-ups */

    GpioCtrlRegs.GPAPUD.all = 0;    // The pullups have to be enabled to minimize the
    GpioCtrlRegs.GPBPUD.all = 0;    // leakage currents, thereby the HALT mode current
   
   
/* Write the LPM code value */
   
    SysCtrlRegs.LPMCR0.bit.LPM = 0x0002;
   
    flash_sleep();    // This function puts the Flash to sleep & HALTs the device   
}

// This MUST be executed from RAM as it will put the Flash to sleep  & device into HALT

void flash_sleep(void)
{
   FlashRegs.FPWR.bit.PWR = FLASH_SLEEP;  // Put the Flash to sleep
   asm(" RPT #7 || NOP");  
   asm(" IDLE");                           /* Force device into HALT  */
   
   while(1){}
}

Matt,

1. The datsheet numbers are valid when all I/O pins are unconnected. Recall that all GPIO pins have an internal pull-up. By default, all GPIO pins come up with the input function enabled. If the pull-ups are enabled and there is external logic connected to the I/O pins that is at a low-state, it could increase the I/O leakge which is reflected on the VDDIO supply (not  VDD). This increase in leakage could be several 10s of uA per pin and adds up when we are talking about a dozen or more of the I/O pins.

2. If the JTAG header is still connected to the DSP, it will increase the current consumption. if you are running thru the emulator, you could issue a "Run free" command and pull-out the JTAG header.

3. You say meter has an accuracy of 0.025%. But, is this figure valid in the range that you are using? On a different note, I prefer using the table-top multimeter (lab bench type) rather than handhelds. In the past, i have seen situations where a handheld multimeter connected to the VDD rail current-starves the core upon powerup, resulting in the device getting into some weird state. I realize you are using the meter in voltmeter mode to measure the drop across a resistor. but, with an expected current of around 150 uA, we are attempting to measure around 150 uV. The measurement uncertainty of the meter at its lowest range could skew the readings pretty significantly. If you have a table-top meter, please connect it in series in ammeter mode.

HareeshJ,

Thank you for your help.  I was finally able to achieve the specified current draw for the Vdd1.8 rail by physically disconnecting the JTAG connector with the example program.  Using RUN or FREE RUN left the current draw at 2.6mA, as before.  I did take the time to use a 0.2uAseries connected ammeter to confirm the numbers.  The readings indicate 66.5uA for the Vdd1.8 rail.

This brings up another question.  Should I be able to reconnect to a 28335 that has been put into HALT mode?  I am consistently unable to do so.  If I have enabled the WAKEINT, I must trigger the selected GPIO pin and wake the processor before the JTAG is able to connect.  If I have not enabled any methods to wake the processor, I am entirely unable to connect to the target without a hardware RESET or power cycle.  I am using a BlackHawk Part #: BH-USB-2000.  The lack of ability to connect to a HALTed target, suggest that I may have a configuration problem?  I have, within the past few days, uninstalled the toolchain, cleaned the registry, and reinstalled the toolchain.  I believe that all of my versions are up to date.  The following link documents the installed versions.

http://community.ti.com/forums/p/3884/14253.aspx#14253

Matt

Matt,

It is not sufficient to just issue a "Run free" command. You indeed need to physically remove the JTAG connector to see HALT mode currents in the range spec'd in the datasheet.

Regarding your other issue of not being able to "reconnect via the JTAG", this is to be expected. The HALT mode kills all the clock domains (including the internal oscillator). In this condition, the emulator will not be able to talk to the device, unless the device has been pulled out of the HALT state by an external stimulus.