Can we assume that by attaching a coin cell to VDD_BAT (with potentially diode to VDD_MCU to prevent continuous drain of the battery), the IMP004m RTC will retain it’s clock after power down and before possible time sync via Wifi ?
Or do we better use an external I2C RTC with dedicated battery backup ?
Alternatively, howl ong would it typically take for the Imp Device to resync it’s local clock after a power- and connection break (without the battery backup referred to above backup) ?
Following along as I also had questions about battery powered RTC on imp004m.
The underlying hardware should be capable of this behaviour, but we haven’t tested or validated it, so I’d feel bad about promising it to you.
The task for testing and validating it (on imp003 as well for that matter) is queued in our backlog, but in the current prioritisation it likely won’t get done until the second quarter of this year.
Following a (complete) power-cycle, the imp’s real-time clock is set correctly as soon as the imp first connects to our servers.
So, if in principle it should be supported by the HW, it should be fairly easy for us to do some quick checks on our breakout board. I guess the following scenario should give a good first indication:
- Vbat on imp separately provided by battery (not sure if they are tied together on the PCB…)
- power up Imp & let it connect
- check clock and let the Imp loop. Every loop, send current clock to the serial port
- disconnect power but keeping battery power on
- kill access point/wifi signal to avoid automatic reconnect
- wait few minutes
- power up Imp
- check on serial port if clock has indeed been retained it’s value AND has progressed by the amount of time we were waiting in power down state
Any comments ?
That would indeed be an interesting and relevant test. I’d also be interested in seeing what hardware.wakereason() would be in that scenario – could you log that to the serial port too?
Note that on imp004 (unlike imp003) the “nv” table does not survive a power-cycle even if Vbat remains powered.
Um, though I should add that, until we have tests for that scenario in-house, we can’t really promise that new improm releases won’t accidentally break it.
I’m a commercial customer and I am designing a new product that is depending on the imp004m RTC…it is important for my application and I am without extra pins for an external RTC. Any chance of moving this up the prioritization and not accidentally breaking functionality with firmware releases?
Most of us that rather active here are commercial customers so I can understand your concern in full.
I can try to do the tests I mentioned in the coming week to know already on a short term basis if it’s working or not (going by the datasheet it should - but that was also true for the LPC176x that we’re using and it turned out not to function correctly as there’s an uP defect in the RTC functionality running on batteries) but I would indeed appreciate that, if functionality is as expected, a test sequence would be added to the standard regression testing to ensure it stays ok with subsequent releases.
Did anyone run a test on this?