I2C component current

[Anonymous]

I am adding an I2C component to my project and I can not figure out why it draws so much current in my project which uses Deep Sleep.

   

My I2C component is setup up as a Master at 400khz.  With the component simply Enabled (not even started), my current draw increases by 800ua to 1950ua.  It does not seem to let the Deep Sleep mode be entered, I even tried I2C_Sleep(); before the Deep Sleep command.

   

Attached are two scope captures of the voltage across my ammeter, which show that the current increase.

   

Any ideas why?

[Bob_Marlowe]

Have a look into the schematics, one I2C is connected to the KitProg (PSoC5) on the PRoC dongle. Be sure to take the other instance

       

Bob

[Anonymous]

Bob,

   

Sorry, did not specify configuration.

   

These are currents from my 3.6v lithium cell that is powering my own pcb which has an EZ-BLE on it.  Not sure how a second I2C component could be involved.

   

Dale

[ETRO_SSN583]

You seeing the pullup current ? Normally in idle state pullups are

   

not drawing current.

       

Regards, Dana.

[Anonymous]

Dana

   

That makes some sense, never considered it would take that much current for 2 data lines that aren't even being used.

   

How do I confirm this?

   

Can I turn the pullups off somehow before I enter Deep Sleep (I2C_Stop() doesn't change things)?

   

Dale

[Anonymous]

What syntax to set SDA and SCL back to high impedance in code if they are only ever assigned pins with I2C component?

[Anonymous]

So, I tried this right before going to deep sleep and got even higher current 🙂  (and that CY_SYS command was really hard for me to find, see this topic 🙂

   

        I2C_Stop();
        I2C_Sleep();

   

        CyGlobalIntDisable;

   

        //sda is p[1]4
        //scl is p[1]5
        CY_SYS_PINS_SET_DRIVE_MODE(CYREG_GPIO_PRT1_PS,4,CY_SYS_PINS_DM_ALG_HIZ);
        CY_SYS_PINS_SET_DRIVE_MODE(CYREG_GPIO_PRT1_PS,5,CY_SYS_PINS_DM_ALG_HIZ);

   

        CyGlobalIntEnable;

[ETRO_SSN583]

When you start I2C, but do not send any data, it should be in idle

   

state, both clk and data high, just use a scope to look at pins.

       

If either or both pins low, then pullups will be drawing current.

       

Regards, Dana.

[Anonymous]

I also have my I2C slave device connected to SDA and SCL.

   

SCL and SDA are low all the time, with and without I2C component enabled.

   

I never do a I2C_Start(), I simply enable the I2C component to get this excess current, my above code was to try to turn I2C off and disable it/pullups to reduce current to where it was before I enabled it by its component properties on .cysch

   

I believe this is unrelated but I never know, if I plug my 5 inch programming cable onto my pcb and do not even plug the other end into the BLE Pioneer Board, my board current fluctuates from an unplugged current of 1150ua to as high as 3000ua.  If I unplug it, current goes back to a steady 1150ua.  Also, I am able to program my EZ-BLE without errors but I can not debug it because the connection is lost as soon as code starts to execute.  I attribute this to issues with SWD lines but was going to look into this next.

[ETRO_SSN583]

To code the pins just write a 1 to the pin, which should turn off the open drain low

   

which is pulling down the pullup.

       

As far as current fluctuation sounds like a floating digital input possible culprit ?

       

Regards, Dana.

[Anonymous]

Still SDA and SCL stay low when I tried setting the SCL and SDA pins high just before Deep Sleep with :

   

I2C_Stop();

   

I2C_Sleep();

   

//sda is p[1]4

   

//scl is p[1]5

   

CY_SYS_PINS_SET_PIN(CYREG_GPIO_PRT1_PS,4);

   

CY_SYS_PINS_SET_PIN(CYREG_GPIO_PRT1_PS,5);

   

RE: current fluctuation, my 5 inch cable leads only connect to +,GND, swd_clk and swd_data when the current starts to fluctuate, I don't know of any external components recommended on the SWD lines and it really is a pain not to be able to debug my board. Any ideas?

[Anonymous]

I just ordered a MiniProg3 so I can try to lower the SWD clock during debugging, hope it helps.

   

AND, I decided to try to communicate with my I2C device even though there is this mystery current when I simply enable the I2C component.

   

So first thing in main(), I start with:

   

    I2C_Start();
    CyGlobalIntEnable;

   

    uint32 status = I2C_I2CMasterSendStart(0x39u,0); //0x39 is slave 7 bit address and 0 is write

   

When I run this and monitor SCL and SDA (they both start LOW) with trigger on SCL, NO activity is captured.

   

The value of status is set to 0x08, which is I2CM_I2C_MSTR_BUS_BUSY and it means that bus is not free.

   

Wow, this is getting tedious again, time to start a case.

[ETRO_SSN583]

CASE yes, dying to know why pins in idle state not high, that's not meeting

   

standard. Nor is it power conscious.

       

Same goes for why GPIO reg write not directing pin.

       

Regards, Dana.

[Anonymous]

I2C master in PSoC or PRoC BLE device doesn't have an internal pull up. I'm assuming you have an external pull up on your board, is that correct?

   

If the SCL/SDATA lines are kept low, it is also possible that the slave device is holding the bus down.. Did you isolate the slave and measured current? When you pace the I2C component in your schematic, the default pin drive state is set to open drain and that shouldn't ideally be consuming any current.

       

3. Looking at the scope capture, it looks like the 

[Anonymous]

I2C master in PSoC or PRoC BLE device doesn't have an internal pull up. I'm assuming you have an external pull up on your board, is that correct?

   

If the SCL/SDATA lines are kept low, it is also possible that the slave device is holding the bus down.. Did you isolate the slave and measured current? When you pace the I2C component in your schematic, the default pin drive state is set to open drain and that shouldn't ideally be consuming any current.

       

3. Looking at the scope capture, it looks like the 

[ETRO_SSN583]

The open drain will consume current thru pullup if its on ?

       

Regards, Dana.

[Anonymous]

When I laid out my pcb a few weeks ago I decided I did not need external pullups if I were to run in 'Standard' mode.

   

Unfortunately, my brain was stuck on the fact that on my PIC projects I run this slave device at 400khz.  So, when I set up the component in software I just set it to 400khz which requires external pullups.

   

SO, I went to 100khz, 'slow' slew rate, and set the i2c pins drive mode to resistive pullup in code as suggested (I have no place to put external pullups right now).

   

BUT, unfortunately, I am using p[1]7 on a voltage divider connected to an ADC_SAR_Seq so I can read battery voltage. 

   

Now I can not build my project because it says I can't mix slew rates on a single port.

   

I try to change p[1]7 slew rate to slow but I can not access that tab because the SDC_SAR_Seq only allows a clock frequency range of 1000-1600 khz and to change p[1]7 slew rate to slow, I think the clock frequency of the SAR needs to be less than 1000khz.

   

Is there a way around this?  Can I read the volts on p[1]7 another way without SAR component?

   

Dale

[ETRO_SSN583]

If you have a pin available use the current DAC feeding a R to make it a

   

VDAC, and pipe that into a comparator and a little code create your own

   

SAR. Note that would effect an 8 bit A/D solution.

       

Regards, Dana.

[Anonymous]

I do not have another available pin.  I will add this to my case to see if there is a way to set clock rate of the SAR to less than 1000khz.

   

For now I just disabled my BatVin pin, its SAR and remmed out a little code so it would build.

   

And WOW the darn thing started working (even with slave device attached)!  SDA and SCL are high after starting I2C, the extra current has seemed to disappear and I can send a:

   

uint32 status = I2C_I2CMasterSendStart(0x39u,0); //0x39 is slave 7 bit address and 0 is write

   

And get a status value of 0 returned and I even see the SDA and SCL bits for that command on my logic analyzer!

   

I think I'm off to the races again. 

   

Thanks, Dana and Undesh, I went back to I2C datasheet after Undesh said external pullups needed and finally remembered my thought process when I laid out the board.

[ETRO_SSN583]

Super, ohms law does work, well sort of if you do not include relativistic effects.

       

Regards, Dana.