DS3231/AT24C32 causing I2C problems

Maybe I picked the wrong Forum... I have a Problem with I2C locking up when the RTC module is powered off/on.

First, I have a custom PCB which piggybacks an Arduino Pro Mini onto the back of a 20x4 I2C display. The PCB also has a MOSFET, tied to Arduino pin 4, which is intended to turn the power to the peripherals (sensors, etc.) on and off on demand to save power.

Using used Nick Gammons I2C scanner with the LCD Display and the RTC/EEPROM attached I get the expected three Messages for all three I2C devices.

The cable attaching the RTC is about 6 inches long, ribbon cable, and I have placed Ground between SCL and SDA on the runs and 5V on the other side of SCL (of course, correcting the order at the RTC). I don't see how the cable could be my problem.

I modified Nick Gammons I2C scanner (temporarily) to turn peripheral power (pin 4) on/off. Setup turns it off, it gets turned on before entering the scan loop and turned back off when scanning is finished. It works fine if the RTC is attached straight to 5V. However, if I attach the RTC VCC to the switched 5V, I2C will lock up. Nicks Programm says "Scanning..." and never goes any further. No devices are reported and I don't get the "Done" message. Sometimes it scans once just fine then locks up, other times it locks up before scanning at all.

I added a delay(1000) after turning the power on and also tried adding a Wire.begin() after the delay. Nothing helps. I2C still seems to lock up.

Does anyone have an idea why turning the power off/on on the DS3231/AT24C32 module locks up the I2C?

You have a battery on the RTC don't you?

Mark

Yes, of course. The RTC module has a LIR2032 on it. My plan was to attach VCC from the RTC to the peripheral power which only goes on for about one/two second(s) every fifteen minutes. This will provide some recharging for the battery.

Right now, in this test configuration, the only peripheral that is being powered by the peripheral MOSFET is the RTC. The final Project will also have things like an MCP9808 temperature sensor, etc. attached.

Of course, when on, the peripheral power also supplies the EEPROM AT24C32 which is on the RTC module along with the DS3231.

The battery only provides backup so the clock won't lose the time Settings and continue running when VCC has no power attached. It isn't possible to read the EEPROM or the RTC without power to VCC.

Take the battery out and try again!

Mark

Mark, just for curiosity?

If I remove the battery, the entire Project goes down the drain as it can/will lose the time Settings.

Along what lines are you thinking with that Suggestion? What do you think may be Happening?

Just for sanity check are you SURE that when in are turning the mosfet on you really get 5V on the devices? Use the multimeter to double check it! I don't want to believe the battery could be the problem but make the test.

Ok, I removed the battery. No Change. I2C Scanner works if RTC/EEPROM module is connected to constant 5V and locks up if VCC is being turned off and back on.

With or without the battery, I am reading 4.99-5.00V on the peripheral voltage when it is turned on and 0.03-0.04 when it is turned off. I will not Claim that my multimeter is high accuracy.

So have you got pullups on the I2c lines?

Mark

However, if I attach the RTC VCC to the switched 5V, I2C will lock up. Nicks Programm says "Scanning..." and never goes any further. No devices are reported and I don't get the "Done" message. Sometimes it scans once just fine then locks up, other times it locks up before scanning at all.

The lock up can occur when the SDA or SCL are shorted to each other or to 5v or GND.

I would look at how that can happen when the switched supply is being used.

I do not provide pullups on my PCB. The RTC/EEPROM module has two small (!) blocks of resistors. 5K and 10K as best I can measure them. As I Interpret the schematics I find on line (whereby the Pictures seem to match but there's no guarantee of exact model) one of those blocks (5K) seems to be connected to SCL and SDA. Fact is, if the power is constant, all three I2C modules work find (20x4 LCD, RTC, EEPROM).

I don't know if the LCD has pullups or not. I believe that pullups are not "normally" necessary because the Wire.h library enables the internal pullups anyway.

I was wondering about the possibility that the LCD and RTC both have pullups and that the sum may be too much/Little. I believe that since everything works when constant 5V is provided to the RTC that the pullups must be ok as they are.

Cattledog, I don't think that is Happening. I checked the voltage on the switched 5V line. When "on" it measures 4.99V-5.00V and when "off" it measures 0.04V to 0.05V.

If shorted to either 5V or Ground, I don't see how it could go up and down depending on the desired on/off state.

That mesure seems ok to me.try to make a more simplistic test by just putting the eeprom powered directly from the pin that is turning on the transistor. The goal is to prove that the i2c scanner can find the device after get powered on “demand”.Since the eeprom will drain very low current (2 mA according to datasheet) it does not put in danger the pin.This will prove that your code is fine and should be able to scan for devices ,even if you have just one there, after it gets turned on “on the fly”.
Post the results

Hugo, I did what you suggested and power (only) the RTC directly from Pin 4. No Change. The first scan worked, the second scan locked up. The MOSFET was completely out of the circuit.

JaBa: Does anyone have an idea why turning the power off/on on the DS3231/AT24C32 module locks up the I2C?

I'm guessing, you have pullup issues. If you are going to turn power on/off to a module then you must ensure that the module does not have any pullups on it, particularly if you end up grounding the power connection when turning off the power.

JaBa: I don't know if the LCD has pullups or not. I believe that pullups are not "normally" necessary because the Wire.h library enables the internal pullups anyway.

Pulllups are always necessary. The internal pullups inside the AVR are too weak. While they can often appear to work, they are way out of spec and if there are no other pullups, you can sometimes experience very strange issues.

In your case, you have external pullups that are connected to the VCC of the RTC module. So depending on what is presented to the VCC pin on that module, the pullup may be a pullup or may not. If the VCC signal drops its voltage when turned off, then the pullup could act as a pull down.

You might want to give my hd44780 i2c LCD diagnostic sketch a try. It is included in my hd44780 library package. The diagnostic sketch includes a test of the i2c signals to see if the external pullups appear to be working as well as an i2c device scanner.

You can install the hd44780 library using the IDE library manager. You can read more about it here: https://github.com/duinoWitchery/hd44780 The name of the test sketch is I2CexpDiag and is one of the examples of the hd44780_I2Cexp i/o class. Even if the diagnostic sketch won't work with your LCD h/w it would be useful to check out the i2c signals which is the first part of the test.

--- bill

The internal pullups inside the AVR are too weak.

If fact it may be that they are to strong ie to high a value for the resistor.

Take a very care full look at i2c org termination

Mark

holmes4:
If fact it may be that they are to strong ie to high a value for the resistor.

Take a very care full look at i2c org termination

Mark

I’m familiar with I2C and its open drain bus and pullup resistors.

When refering to a pullup being “strong” or “weak” it typically means that the pullup resistor is creating a strong or weak pullup signal - not that it is a larger or smaller resistor value.

I was referring to the pullup being too weak which implies that the resistor value is too large.
The bigger the resistor value, the weaker the pullup since a larger value resistor restricts the current more than a smaller resistor and hence the larger resistor will create less of pullup demand than a smaller resistor value.

The AVR datasheet shows that the internal pullup internal resistor is between 20k and 50k.
That sized resistor creates a fairly weak pullup signal that is not strong enough to make the i2c signals work properly in certain situations. (the resistor value is too large)
And that is why I said:

The internal pullups inside the AVR are too weak.

— bill

I don't think the pullups are "off", per se. When the RTC VCC is connected directly to 5V everything works fine. When it is connected to switched 5V, it sometimes works once and never again until a reset occurs.

bperry may have something though. Fact is that the switched 5V Drops to near Zero when turned "off". I don't understand why that would be a Problem though. No I2C activity ever takes place unless the switched 5V is on. Right now, I turn the peripherals on, do a delay(500) and then perform the I2C scan and turn the switched 5V off when done.

Nonetheless, I will use the suggested diagnostics. I can't do it now because I have to leave for work but will get to it this evening. I have done some analogRead on A4 and A5 and have noted that when it locks the values are relatively low (400-500) so that also supports the theory from bperry that SCL/SDA are being pulled low...

I'll be back in about ten hours.

Hiya Jaba. I straw-grasping here, but have you tried adding

   Wire.beginTransmission(0x68); // address DS3231
  Wire.write(0x0E); // select register
  Wire.write(0b00011100); // write register bitmap, bit 7 is /EOSC
  Wire.endTransmission();

to your setup() function?

Chris, no, I hadn't tried that. For the Moment, I am only testing the Hardware using Nick Gammons I2CScanner, modified slightly to also turn the peripherals on/off. I'm willing to try anything however. For the Moment, I can't try anything because I am 50 miles away from my Project.

I'll try all suggestions this evening (Central European Time).

Chris, your test was the easier to implement so I luckily did it first... You can grab at straws anytime you like in my book! I don't have the faintest idea what you suggested. As far as I can tell your suggestion has to do with the SQW pin which isn't even attached... But, what can I say. It works.

Would you mind explaining it to me? Knowing it works it half the recipe but I'd also like to understand it.

@bperrybap: I didn't try the library this time, but I think I will download it anyway. I like the idea of having some kind of I2C diagnostic tool at my disposal for the next problem that comes up.

Karma added for both of you. Thanks!