brid0030
- 4th January 2018, 21:26
I'm trying to communicate with a Micro Crystal RV-1805-C3 real time clock using a PIC12LF1840. This RTC has a high impedance pin that can be employed to switch off everything but the clock and then power everything back up again when needed. So you can get a super low sleep current for the system (like 20 nA).
When the PIC powers up, the first thing I want it to do is read parameters from the clock on an I2C bus. I've found through experimentation that the first attempt to communicate with I2C consistently fails both for reading and writing. After that it works fine. I've tried adding things before the first I2C communication such as long pauses and simulated stop conditions, but they have no effect. There are two things that seem to work. First is just to insert a dummy I2C command addressed to a non-existing device (or just issue a read to the clock and ignore the results). Second is to have the clock implement a brief delay before it shuts down the PIC. That is, you have the clock wait for a period of 8ms after the last I2C command before shutting things down. Somehow this wait period enables the PIC to wake up and do I2C coms as usual. I have no idea why. I just have a pause following the go-to-sleep command to the clock.
Ideally I would like to have this system minimize its awake time. It's not a huge deal to have the dummy I2C command as a work around, but I would still like to understand what's going on. I haven't scoped the I2C lines yet, but I could if this this stumps the forum.
When the PIC powers up, the first thing I want it to do is read parameters from the clock on an I2C bus. I've found through experimentation that the first attempt to communicate with I2C consistently fails both for reading and writing. After that it works fine. I've tried adding things before the first I2C communication such as long pauses and simulated stop conditions, but they have no effect. There are two things that seem to work. First is just to insert a dummy I2C command addressed to a non-existing device (or just issue a read to the clock and ignore the results). Second is to have the clock implement a brief delay before it shuts down the PIC. That is, you have the clock wait for a period of 8ms after the last I2C command before shutting things down. Somehow this wait period enables the PIC to wake up and do I2C coms as usual. I have no idea why. I just have a pause following the go-to-sleep command to the clock.
Ideally I would like to have this system minimize its awake time. It's not a huge deal to have the dummy I2C command as a work around, but I would still like to understand what's going on. I haven't scoped the I2C lines yet, but I could if this this stumps the forum.