TMS320C5535: SPI peripheral more than doubles current consumption

Tsvetolin, 

Unfortunately, this custom board is for a military application so I cannot post the schematics online. This is a battery powered application, where the battery operates at 6V. However, I'm currently supplying 6V using a DC power supply instead of batteries because this project is still under development.

I'm measuring the current at the battery holder leads, so I'm measuring current of the whole system on the custom board but only the C5535 is on. All other ICs have been disconnected from the system, so the C5535 is the only IC consuming power. I have TI buck regulators that step down the 6V to 3.3V (DVDDIO/LDOI/DVDDRTC) and 1.3V(CVDDRTC).

So far, the C5535 has been operating as expected. Like mentioned in the original post, the issue I'm trying to solve is that the C5535 draws 20mA without the SPI peripheral, but then begins drawing 70mA once the SPI peripheral is initialized using SPI_init().

Best, 

Eddie

Hi Eddie,

* Can you measure each power rail separately?

- DVDDIO vs CVDD vs any other supplies

- to achieve this, remove a component and insert current meter in series

- or measure voltage drop across a precise resistor in series

* Have you seen the Power estimation spreadsheet

- Link to the sheet in http://www.ti.com/lit/pdf/sprabn0 

- Can plug in the use case to see how closely your measurements match

- The maximum DVDDIO current I was able get from this tool for SPI was 20.942mW (6.346mA * 3.3V)

- What is the SYSCLK frequency, and resulting SPI_CLK frequency?

- Does the power increase when SPI activity is on the bus? What is the difference?

* Refer also to the C5535 schematic review checklist

- http://www.ti.com/lit/pdf/sprac31

- In particular floating inputs are capable of increasing DVDDIO power consumption by oscillating through the input threshold region. We advise terminating all IOs with internal or external resistors.

* Are any other peripherals getting enabled (inadvertently)?

- Before and after the jump in power consumption, what are the contents of PCGCR1/2? What contents are in EBSR (mux mode selection)?

* What CSL version are you using?

- SPI_Init includes a peripheral reset to the PG4 group of peripherals

- PG4_RST controls the reset to I2S2, I2S3, UART, and SPI.

- Perhaps the power is actually coming from one of these peripherals.

- Try resetting all peripherals earlier than SPI_Init, and commenting the peripheral reset step out.

* Is the power consumption repeatable on multiple boards?

* What is the IO voltage?

- There is greater variation across parts in DVDDIO current consumption at 3.3V than at 1.8V.

* For accurate power measurements when running with emulator, we recommend using the "Free Run" Run mode, and disconnecting the JTAG pod from the board to avoid its power consumption. We also recommend a pull-up on the TDO JTAG pin.

Summary:

- Isolate power consumption in system (through the buck? into DVDDIO?)

- Use lowest IO voltages possible to reduce power

- Check software peripheral reset impact on power

- 70mA is very high, check for shorts

Relevant threads:

https://e2e.ti.com/support/processors/f/791/t/728102?TMS320VC5505-Estimating-a-part-to-part-deviation-of-3-3V-supply-current

https://e2e.ti.com/support/processors/f/791/t/728704

Regards,
Mark

Mark, 

Thank you for your very detailed reply. I'm currently in the process of taking measurements and figuring out the source of the high current draw. 

I was testing your theory about PG4 peripherals causing the increase current draw, but I have found that the following line of code is what causes the current draw to spike from 20mA to 70mA:

	CSL_FINS(sysRegs->PCGCR1, SYS_PCGCR1_SPICG, CSL_SYS_PCGCR1_SPICG_ACTIVE);

This is the line of code found in SPI_init(void) (the library version number I'm using is 3.08). For some reason the gating of the SPI peripheral is making the current spike. I have already opened the MISO, MOSI, and SPI_CLK traces to see if these lines were possibly shorting, however, the issue persists. 

The DVDDIO, LDOI, and DVDDRTC pins are all being driven by the same 3.3V regulator. Since they are connected by traces, I cannot give you the current of only DVDDIO. However, I the current consumption of DVDDIO, LDOI, and DVDDRTC together is 28mA BEFORE CSL_SYS_PCGCR1_SPICG_ACTIVE is initiated (28mA seems to line up with what the spreadsheet says). 

The current consumption of DVDDIO, LDOI, and DVDDRTC together is 82mA AFTER CSL_SYS_PCGCR1_SPICG_ACTIVE is initiated. 

Some answers for the points you made:

- The SYSCLK is 100MHz. Although the current draw is high, the DSP still operates normally and doesn't malfunction. I am able to communicate to external ICs with SPI_CLK set at 5MHz. 

- The current draw stays fixed at ~70mA regardless of the SPI bus being used or not. 

- Using SPI_deInit() does not help:

    // Current = ~28mA
    SPI_init();
    // Current = ~82mA
    SPI_deInit();
    // Current is still = ~82mA, expected it to be ~28mA again 

- All unused IO pins have been grounded, there are no unused open pins. 

 - PPMODE = 1, SP1MODE = 1, SP0MODE = 1. These modes have been set and are expected. There is no change after CSL_SYS_PCGCR1_SPICG_ACTIVE is initiated. 

I hope the information above is helpful to you. I'm still in the process of troubleshooting and will update you on any new findings, but I'm looking for possible shorts as of now. 

Best, 

Eddie

Mark,

Sorry, I accidentally pressed the "This resolved my issue" button. It's not resolved yet, but we'll get it!

PCGCR1 = 0x7BFB before CSL_SYS_PCGCR1_SPICG_ACTIVE is initiated. PCGCR1 = 0x7BF9 after the CSL_SYS_PCGCR1_SPICG_ACTIVE is initiated.

PCGCR2 stays = 0x003B either way. 

ESBR stays PPMODE = 1, SP1MODE = 1, SP0MODE = 1 either way

The LDOO pins have been connected directly to the CVDD pins with traces, so unfortunately I can't measure the current going to CVDD for you. 

To be extra safe I open all the SPI_CS pins to make sure they weren't shorting, but the issue persists.

Finally, you bring up a good point about the GPIO Pins accidentally being driven to high. I verified that IOOUTDATA1/IOOUTDATA1 = 0x0000, so this probably isn't the issue. It could be possible that I'm driving a non-GPIO pin to ground accidentally, so I'm going to double check the datasheet and make sure there are no non-GPIO pins accidentally being grounded. 

Best, 

Eddie

Mark,

I know I may have confused you by pushing the "This resolved my issue" button, but it was accidental. Just a friendly reminder that I have not found a solution for the high current consumption yet and this is still an ongoing issue that I must resolve.

Best,

Eddie

Mark, 

I hope your weekend went well, I don't mean to rush you either. 

If you believe that purchasing a C5535 eZdsp board would be the best course of action to troubleshoot this problem, I can request to have it purchased. Unfortunately, I don't currently have that board. 

Regarding the clock gates. When I open all of the except for SYSCLKDIS, the high current persists. I even tried the following:

	CSL_FINS(sysRegs->PCGCR1, SYS_PCGCR1_SPICG, CSL_SYS_PCGCR1_SPICG_ACTIVE);
	CSL_FINS(sysRegs->PCGCR1, SYS_PCGCR1_SPICG, CSL_SYS_PCGCR1_SPICG_DISABLED);

I expect the current to go from 20mA to 70mA back to 20mA (I set breakpoints to give myself time to measure the current). However the current never returns to 20mA after disabling the SPI clock gate, it stays at 70mA. 

One more note. I imported the CSL_SPI_InternalLB_example project into my workspace and chose the appropriate .gel for the c5535(c5505evm_pg20.gel). I found that the same thing happens in the example. After the example initializes: 

	CSL_FINS(sysRegs->PCGCR1, SYS_PCGCR1_SPICG, CSL_SYS_PCGCR1_SPICG_ACTIVE);

the current jumps up 30mA. 

For reference, I've been measuring current across J22 (refer to the schematic).

I assumed that implementing the dsp_lib would take care of all the initialization steps found 8.3.3.1 SPRUH87, is this not the case?

Let me know if there's any additional information I can get you. 

Best, 

Eddie

Mark, 

The schematics I sent you represents how the C5535 is currently wired. I have not removed any of the 0ohm resistors yet. This product is still going through its prototype/development phase so the 0ohm resistors are there in case any changes or jumper modifications needs to be made. 

I have not had any major problems with the C5535 besides this weird SPI power issue. I will consider asking for the C5535 eZDSP if resolving this issue takes longer than expected.

I did as you suggested and changed the PPMODE from MODE 1 to MODE 6. Unfortunately the same issue persists. 

The current does scale somewhat with different PLL speeds:

100MHz: ~22mA without SPI initialized, ~70mA with SPI initialized

60MHz:   ~13mA without SPI initialized, ~60mA with SPI initialized

However, changing the SPI CLK speed did not make any noticeable difference in current consumption:

    /* Set the hardware configuration */
    spiCfg_ADS.spiClkDiv  = 20;
    spiCfg_ADS.wLen       = SPI_WORD_LENGTH_32;
    spiCfg_ADS.frLen      = 1;
    spiCfg_ADS.wcEnable   = SPI_WORD_IRQ_DISABLE;
    spiCfg_ADS.fcEnable   = SPI_FRAME_IRQ_DISABLE;
    spiCfg_ADS.csNum      = SPI_CS_NUM_0;
    spiCfg_ADS.dataDelay  = SPI_DATA_DLY_0;
    spiCfg_ADS.csPol      = SPI_CSP_ACTIVE_LOW;
    spiCfg_ADS.clkPol     = SPI_CLKP_LOW_AT_IDLE; // SPI MODE 1
    spiCfg_ADS.clkPh      = SPI_CLK_PH_RISE_EDGE;

100MHz / 20 = SPI clock of 5MHz

100MHz / 1000 = SPI clock of 100kHz

In both cases, the current consumption was still at ~70mA after  SPI_config() was called. 

Best, 

Eddie