DS3231 Oddities with PIC18F25k22

I have a board with an 18F25K22 micro, a MCP23017 port expander, an I2C eeprom and a DS3231 clock chip. When programming the 18F25k22 via ICSP, after some number (highly variable) of programming cycles, the DS3231 gets unhappy and hangs the I2C bus. Leaving the board unpowered for an hour or more (sometimes shorter periods work, sometimes longer) will restore proper operation. I have boards of two different designs and applications that have the same problem with the DS3231 clock chips. Other similar boards with an MCP23017 port expander and no clock chip never experience problems like this.

The board runs off a 5 volt supply and every chip has a 0.1uF bypass cap. The I2C bus has 4.7k pullups. I use a PICkit 2 for programming.

Any ideas why this is happening? Or how to eliminate the problem/expedite recovery?

From the data sheet, this may do the trick:


"The I2C interface is accessible whenever either VCC or VBAT is at a valid level. If a microcontroller connected to the DS3231 resets because of a loss of VCC or other event, it is possible that the microcontroller and DS3231 I2C communications could become unsynchronized, e.g., the microcontroller resets while reading data from the DS3231. When the microcontroller resets, the DS3231 I2C interface may be placed into a known state by toggling SCL until SDA is observed to be at a high level. At that point the microcontroller should pull SDA low while SCL is high, generating a START condition."

That is very interesting. I hope that you will report back any success or failure. I am a little suspicious about the relationship between what they are saying and what you are experiencing in this sense: Yeah, if there is a reset while the master is reading the clock, I guess I could see getting out of synch since the DS side is still live and waiting (assuming either a separate Vcc or a battery).

But, are you reading the DS during your programming cycles? Also, why would leaving the board unpowered for an hour or so fix the problem - why not just one second?

Please let us know how it turns out.

BTW: Not a word about it in their tutorial, Tips for Writing Bulletproof Real-Time Clock Control Code.

What I do on bootup is to check if the data line is being held low. If it is then the bus will hang. The solution is to clock the clock line until the data line is released.

HTH

Mike.
Edit, Jon beat me to it.

I can't say positively that this solves the problem, but I did have one case where it hung after programming and cycling the power to restart the program did it. I'm toggling SCL about a dozen times at the beginning of the program before initializing I2C.

I'm continuously reading/writing to the MCP23017 and reading the clock in a loop, so it's almost certain something is happening on the bus when I load new code. The clock chip does have a backup battery, so that may explain the hangups for extended periods.

I'll let you know how it goes as I finish up my code.

Do you have the RST line of the DS3231 connect to MCLR?

If so, when you program via ICSP the PK2 will raise that line up to 9V in order to get it into programming mode.
That might upset things.

No. I am hoping to use the reset line (which is only an output on the DS3231) to trigger one last reading in my data-collector application on loss of power. Its activation point may be a too low a voltage for my 18F22K25 to operate. I still have a little experimenting to do in that regard.

I think it can be used as both output AND reset input. It's an open-drain with an internal 50K pullup to VCC.

That said, my money's on the I2C state getting hungup. Just figured it's something to be aware of...

It can be an input in the sense that a connected button press will generate a controlled reset to a connected micro. But the datasheet clearly states that asserting the reset pin has no effect on "the internal workings" of the chip or words to that effect.

Pommie said:

What I do on bootup is to check if the data line is being held low. If it is then the bus will hang. The solution is to clock the clock line until the data line is released.

HTH

Mike.
Edit, Jon beat me to it.

Click to expand...

I have been reading about this issue (and I admit that I did not know about it specifically before). Check me, but it seems to me that what you are describing is a sound and a conventional remedy.

See AN10216-01 I2 C Manual (p17 / slide 42).

See post #4 here.

Then I came across this thread, where SCL rather than SDA is being held low by the slave. Following up, I was pointed to **broken link removed** (see section 3.1.16). It seems that, programmatically, this is a more difficult situation to recover from.

I have the luxury of discussing this conceptually in the hope of establishing and retaining some better practices. Jon is dealing with an actual problem on the bench - I get that.

But (and again, check me) it seems to me that maybe the best "solution" is to check, on bootup, if SDA or SCL is being held low and to act differently in each case (and, again, if it is SCL, I do't know exactly what you can do since power cycling an RTC with a battery backup is cumbersome).

Thoughts?

Great information DrG. I appreciate the good discussion guys.

I think adding a check of levels and issuing a string of clock pulses to the start of my I2C initialization scheme is a good idea.

I always cycle the device reset pins (if the device has one) at the start of programs to get everything into a known state. This is to avoid a situation where the micro is reset after programming, but power never removed from the board, which can leave I2C devices in an unknown state.

Thanks for the responses!

(and, again, if it is SCL, I do't know exactly what you can do...

Click to expand...

If a device is holding SCL low then you're screwed unless it has a reset mechanism you can get at.

tumbleweed said:

If a device is holding SCL low then you're screwed unless it has a reset mechanism you can get at.

Click to expand...

That would be clock stretching to infinity which will only happen in a fault situation.

Mike.

A quick follow up - since I added the short routine to bang on the clock line, I haven't had the lockup problem again.

Thanks for the help!