1
\$\begingroup\$

In my project I have connected multiple sensor breakout boards to a Arduino-proMIni running at 3.3V and 8Mhz as follows on a fabricated pcb but preserving the original board layouts (so that I can connect them via traces instead of loose wires)

hardware architecture

To save power I am using the digital GPIO Pins to power all the breakout boards that are running on I2C with Vin = 3.3V.

The breakout boards for different sensors have pullup resistances for SDA/SCL lines (pulled up with Vin) and configured as follows:

pullup resistance and .1mm trace lengths

When I power on the board, as long as the external eeprom is ON (but no reads or writes are happening), there is no serial output for the i2c line.

When I turn off the eeprom, the i2c line only works if all others sensors are on. Turning any one or more of the sensors off, gives no serial output for the i2c line.

After researching online I realized that we need to give a dedicated Vdd line to the pullup resistances of the SDA/SCL lines instead of the Vin lines, as turning Vin off will also pull-down the i2c lines.

So I removed the pull-up resistances on all the breakout boards and added 5k pullups to the SDA/SCL pins on the MCU with the Vdd.

Even after doing this the i2c lines only work after the external eeprom is turned off.

As For the other sensors -

  • The RTC now works only when all other sensors are off. Switching the RTC on is most likely adding a lot of noise in the i2c output because the values changes on the serial monitor change asa it is turned on and come back to normal when turned off.
  • The capacitive sensor works only when the accelerometer is on.
  • The current odometer and the accelerometer work without any problems.

Can someone please help me figure out why all of this is happening? Can this problem be solved by merely choosing the right pull-up resistances or is it a higher order problem? Is it possible that because I am using a 30cm wire for the Accelerometer, the entire bus capacitance is increasing, adding too much noise in the system when multiple slaves run simultaneously. And hence will it help if I shift the accelerometer on the SPI protocol and decouple it from I2C?

All sensors are running at <100Khz except the eeprom which is running at 400Khz.

Update:

So I took everyones suggestion below and made 2 pcbs. In one I powered all the sensors to the Vcc line and even pulled up the i2c line on Vcc. In the other I powered all the sensors with the GPIO pins (but keeping them always on HIGH) just like before and pulled up the i2c lines with another GPIO (so that I can pull them down when all the sensors are simultaneously LOW to avoid case [4] as pointed out by @maple below). And guess what? The GPIO powered sensors are working flawlessly while in the Vcc powered ones the i2c line i.e SDA, freezes after few seconds. This happens in the case when I am trying to communicate with the FDC1004, the adxl and ina219. RTC doesn't seems to be affected. Any clue why this could happen?

\$\endgroup\$
  • \$\begingroup\$ If you have access to an oscilloscope, check out the I2C lines and make sure you're getting decent rising edges. \$\endgroup\$ – Annie May 7 '18 at 15:22
  • \$\begingroup\$ That's scheduled for tomorrow. Thanks. \$\endgroup\$ – designDemon May 8 '18 at 17:25
  • \$\begingroup\$ somewhat related: I2C pull-up resistors on modules and breakout boards \$\endgroup\$ – Nick Alexeev May 10 '18 at 2:17
  • \$\begingroup\$ Exactamento! So I removed the 4.7k resistors from all the boards and added the closest value, 5k to the sda scl lines on the uC. But now the RTC seems to be disturbing the i2c line. I think I should decrease the pull-ups further no? Will also try disabling the internal pullups in the wire library. \$\endgroup\$ – designDemon May 10 '18 at 10:09
  • \$\begingroup\$ Solved the RTC problem, which was happening because it had a dedicated EEPROM on the board. Had to solder it out too. \$\endgroup\$ – designDemon May 15 '18 at 7:17
2
\$\begingroup\$

You can't work like that.
You have no idea what is inside a chip and thus the moment you turn the power off you have no idea what the inputs will do. They can have a low impedance path to ground or between the two lines.

A system like yours needs isolating switches which disconnect the device when it is powered off. Have a look at transmission gate chips.

In general you design is violating good design rules. Using GPIO pins to power boards: horrible! Just use a power switch: https://e2e.ti.com/blogs_/b/powerhouse/archive/2016/02/03/when-to-use-load-switches-in-place-of-discrete-mosfets

\$\endgroup\$
  • \$\begingroup\$ Hey I am new to this so can you please help me understand why is it not advisable to use the GPIO pins to directly power the boards when they are capable of supplying the required voltage and current values even if all sensors are running simultaneously. Also even if use the load switches to turn off the boards, won't they have a similar effect on the unknown inputs that you mention? \$\endgroup\$ – designDemon May 8 '18 at 17:35
  • \$\begingroup\$ A good supply has a low impedance to e.g. quickly charge decoupling capacitors which should be near to each IC. GPIOs don't have that. With GPIOs you will also have CPU noise coming out and power noise from a load will feed back into the CPU. I never said that load switches would solve your problem, it was a general remark. \$\endgroup\$ – Oldfart May 8 '18 at 17:48
  • \$\begingroup\$ Understood. That makes sense. But can you suggest a solution on how can I toggle the sensor boards off to save power without disturbing the SDA SCL lines. Should I use power switches on the boards and transmission gate switches on their individual SDA SCL lines to disconnect them completely when the sensors are off. Because even now when I physically disconnect the SDA SCL traces of any of the sensor boards the i2c line seems to give stable outputs on the serial for the rest of the boards that are on. The Ext Eeprom seems to be the biggest culprit of them all, completely freezing the lines. \$\endgroup\$ – designDemon May 9 '18 at 2:16
  • \$\begingroup\$ Same question popped up yesterday: electronics.stackexchange.com/questions/373206/… \$\endgroup\$ – Oldfart May 9 '18 at 8:36
  • 1
    \$\begingroup\$ Your third paragraph is simply wrong. Even when doing only write cycles, the slave must acknowledge every byte transmitted by the master. The SDA line is always bidirectional. \$\endgroup\$ – Dave Tweed May 13 '18 at 14:30
2
\$\begingroup\$

There are so many problems with this design I don't even know where to begin.

  1. In the blog you've linked to there is a limiting resistor to deal with decoupling capacitor charge current. You did not mention anything like this in the description. Even if you don't have external capacitors it doesn't mean the modules don't. In fact, most of them do. I hate to think what these currents do to your MCU pins.

  2. Following on the above, every time you switch devices on/off you charging/discharging those caps. If you constantly interrogating devices in a loop I suspect you will end up losing more power on this than saving it.

  3. Most devices have power-up time. You have to account for this in your code with delays between applying power and beginning to communicate.

  4. Most devices have I/O voltage specified in "absolute maximum ratings" as referenced to Vdd, e.g. "Vdd + 0.5V". If you remove power from the chip leaving its I2C lines connected to the bus you are way over the safe limits, basically frying those chips.

  5. Following on the above, MCU does not output rail-to-rail. "1" does not mean you have slave Vdd at MCU Vdd and consequently, the I2C pull-up voltage. Although this difference is much less concerning than in #4.

  6. If the EEPROM is running on different speed than the rest of modules you cannot have any of them ON simultaneously with EEPROM. You've mentioned this several times but as a problem to overcome, not as a conscious design decision. Many MCUs have more than one hardware I2C lines - use them to group your slaves by bus speeds.

  7. Following on the above, different bus speeds require different pull-ups. One more reason to keep groups of slaves on separate lines.

  8. Speaking of the pull-ups, 5K is probably too weak for 400KHz.

  9. If you still want to use single I2C port for everything keep in mind that switching it's speed is not instantaneous after you reconfigured the clock registers.

  10. Many devices, especially sensors (like accelerometers) have support for "sleep" or "low power" mode. By using these you will probably save more power than with all this GPIO mess. AND you will have much faster system because waking up times are shorter than power-up times.

In short, if you carefully address the concerns above (and maybe others I didn't think of) you just might end up with working system. But it will probably draw more power and have more components than you can have with either using slaves sleep mode or simple power switch (L9826, MIC5891 etc) and I2C bus mux combination.

UPDATE:

Here is a little math for illustration: FDC1004 requires at least 1.1uF decoupling capacitors. Not accounting for loses this equates to 5.9895uJ energy to charge them on power up. At the same time current during sampling is 750uA, and it takes under 1/400 sec to finish (probably much less than that), which equates to 6.1875uJ. Meaning: simple switching power Off and On again requires as much energy as it takes to do the measurement itself! And you still have to do the measurement after power-up.

Standby current of 29uA translates into 95.7uJ, i.e if you do the sampling more than 16 times per second you already wasting more energy than FDC1004 would consume if left in standby.

\$\endgroup\$
  • \$\begingroup\$ Hey. Thank you so much for this detailed answer. Reinforces a lot of the concepts I've been going through online \$\endgroup\$ – designDemon May 14 '18 at 18:21
  • \$\begingroup\$ However, the current design just the way it is seems to be working fine now. The external eeprom is kept off and is only on when everyone sensor is off. The SCL and SDA lines of all the breakout boards are completely decoupled from their individual voltage inputs i.e the GPIO pins and pulled up using the stable vdd. I am able to toggle all the sensors on off, except the current sensing chip, which when turned off is still causing one of the capacitive sensor to turn off. Beating my head on why it's happening. \$\endgroup\$ – designDemon May 14 '18 at 18:31
  • \$\begingroup\$ Also, could you explain point 1. I don't understand how that will affect my mcu pins. Because the maximum current draw by each breakout board is well within the max limits. And regarding point 4, I always thought Vdd + 0.5 meant if chip can be powered by 3v these pins can take 3.5V. I thought it meant that if the chip was being powered by say 2 V or .4V, these pins could still take in 3.5V. if this case my chips should have already fried. Also there is this weird thing happening. When I turn all GPIOs low the mcu drains 40mA current and if I keep even one GPIO ON the current drained is <5mA. \$\endgroup\$ – designDemon May 14 '18 at 18:41
  • \$\begingroup\$ #1: maximum current draw is for stable powered condition. Most of the boards have decoupling capacitors between Vdd and Gnd, so when you apply power to the board you are charging those capacitors through you IO pin, without any limit on current. This is explained in the blog you referred to. #4: no, that number in datasheet does not mean maximum Vdd, it means actual Vdd applied at the time. The chips might survive what you are doing to them but you are increasing the probability of failure in the long run. \$\endgroup\$ – Maple May 14 '18 at 18:52
  • \$\begingroup\$ Re: the rest of it, take a look at the last paragraph again. As I said, it is possible to make the whole thing work, however... it is like nailing the screws - they will hold but the result will not be pretty. For example, the ADXL345 draws only 0.1 μA (!) in standby mode. And it is ready to communicate much faster than after power up. \$\endgroup\$ – Maple May 14 '18 at 19:08

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.