For testing, can you please do the following steps also?
1. Remove all the code in your application and just put the system in Hibernate Low mode mode. Measure currents by placing and without placing the I2C component in the schematic and update us the values.
2. If you are not seeing any difference in currents in the above step, start the I2C component by calling I2C_Start() just before calling the Hibernate API (In the case where you have placed the I2C component in the schematic) and measure the current once and let us know the results.
3. There are no physical connections to the I2C pins you are using. correct? Have you removed the module out of the baseboard and doing the measurement? Or you are measuring the current by keeping the module on the baseboard?
1. Without I2C component, I = 120nA. With I2C component (set up as Master with 100kbps comms speed), I = 350uA
3. Yes, I have removed the module out of the baseboard and am applying 3.3V to this via an external power supply, through which I am measuring the input current
I have the pins set up as SDA = P0, SCL = P0, which is the default. I swapped these over to SDA = P3 , SCL = P3 and the current in Hibernate mode, both WITH and WITHOUT the I2C component in place is now ~ 120nA. So, its got something to do with using the P0 and P0 pins for the I2C bus. Any idea why this would be?
I also tried the other pin combination options (P5/P5) and these also gave 120nA in Hibernate.
Unfortunately my prototype hardware design is set up to use P0 and P0 and so I’d like to be able to configure the software to work with this arrangement.
Anyone out there in Cypress Land got any idea what the current in Hibernate mode is so much higher when I'm using P0 and P0 for the I2C pins, compared to any of the other combinations that are available?
I want to get my hardware functioning as required, but can't with the extremely high current drain in Hibernate mode compared to what it should be
We found no specific reason for the high current consumption on the pin P0 and P0. There might be issue specific to the silicon that you are using.
If you have another PSoC IC with you, please do a swap test and check the current consumption (Due to limited access to resourses we are not able to measure currents at our side right now). If the swapped device also fails, then we will create a Failure Analysis case and will investigate this issue more deeper.
Apologies for the delay in responding - I was on another project for the past few months.
I've just got back onto this, and I'm still seeing this issue.
All my of recent testing was done using the AN86233_PowerModes example project, and I was setting the power mode to Hibernate. I simply added an I2C component to this project (never actually enabled it or started it) to allow me to allocate the I2C pins accordingly when I wanted to check the current draw with I2C enabled.
In all cases I have Debug Select set to "GPIO"
Results I see, which are consistent across several PSOC 4 BLE Modules which all use the CY8C4247LQI-BL483 chip, are:
- No I2C component: Hibernate current < 150nA
- I2C component, pins allocated to P0 & P0, Hibernate current < 40uA!!
- I2C component, pins allocated to P0 & P0, Hibernate current < 200uA!!
- I2C component, pins allocated to P1 & P1, Hibernate current < 100uA!!
- I2C component, pins allocated to P3 & P3, Hibernate current < 150nA (so, similar to when there was no I2C component)
- I2C component, pins allocated to P5 & P5, Hibernate current < 150nA (so, similar to when there was no I2C component)
In the short term, this just means I need to redesign my hardware to utilise either pins P3/P3 or P5/P5 but it would be good to know if there was something I could do with my current hardware (which uses P0/P0) in order to get the hibernate current down.
Digging into the data sheet for the PSOC 4100 BLE chip, I read this on the I2C functionality:
SCB1 is fully compliant with Standard-mode (100 kHz), Fast-mode (400 kHz), and Fast-Mode Plus (1 MHz) I2C signaling specifications when routed to GPIO pins P5.0 and P5.1, except for hot swap capability during I2C active communication. The remaining GPIOs do not meet the hot-swap specification (VDD off; draw < 10-μA current) for Fast mode and Fast-Mode Plus, IOL spec (20 mA) for Fast-Mode Plus, hysteresis spec (0.05 × VDD) for Fast mode and Fast-Mode Plus, and minimum fall-time spec for Fast mode and Fast-Mode Plus.
■ GPIO cells, including P5.0 and P5.1, cannot be hot-swapped or powered up independent of the rest of the I2C system.
■ The GPIO pins P5.0 and P5.1 are overvoltage-tolerant but cannot be hot-swapped or powered up independent of the rest of the I2C system. ■ Fast-Mode Plus has an IOL specification of 20 mA at a VOL of 0.4 V. The GPIO cells can sink a maximum of 8 mA IOL with a VOL maximum of 0.6 V.
■ Fast mode and Fast-Mode Plus specify minimum Fall times, which are not met with the GPIO cell; the Slow-Strong mode can help meet this spec depending on the bus load.
S0, seems to indicate P5.0 & P5.1 are the best pin pairs to select when implementing the I2C and it seems to be the only pin pair I can use and reliably get the Hibernate current down to < 150nA.
I'm actually using Standard-mode in my implementation, so not sure how any of the above would apply, and what the impact is, but my conclusion is: "If you want to limit the Hibernate current to quoted levels, you MUST route your SCL/SCA through P5.1/P5.0"
I'd be interested to understand why the other GPIO cause issues.