Agree and your approach would certainly work. I have another idea I want to test though. I suspect the issue is that when I connect the ICSP header, to the board, the Vcc from the header will energize the other devices and bring the i2c pull-ups into play. So, I am thinking I will put a Schottky diode between the watchdog and Vcc. That way the ICSP will only energize the Watchdog.
I plan to do another OSHPark run so, if my somewhat crazy idea does not work, I will implement jumpers as you suggested. I am trying to do all the Watchdog stuff under the Particle device so not much clearance there.
Here is the next version which I plan to send off to OSHPark today. I put a Qwiic connector on as well as connectors for other devices and one legacy 2x3 header. The Watchdog jumper for EN and RST as well as the ICSP header are under the Particle device socket. Take a quick look as I need to keep this project moving forward.
Nice work, Chip. I’m wondering what your thought process was in using the two load switches on the Li+ and VUSB rails since in your previous version you used the EN pin to enable or disable the circuit. In the current design your battery won’t charge if the power switch is off. Is that intentional? I’ve been considering the pros and cons of both approaches for my own carrier and would be interested in your thoughts.
I wanted to have a switch to turn off power to the device.
I looked at the current it would have to support and realized there were no surface mount switches that could switch off both DC-In and LiPO and carry the current that they could potentially support. Of the 4,000 slide switches on Digikey - the highest DC current a slide switch can support is 300mA.
So, I decided to use the load switches which then allowed the current I needed.
Slides switches - who knew!
So, when the slide switch is off, the battery backup for the RTC is powered but that is it. This should be good for storage and shipping. The intent is for the device to spend most of its life with the switch on which - as you point out - enables charging. I chose this over the - pull the battery connector off - approach as those JST connectors are a bear and I don’t want a park technician damaging the connectors.
That does make sense, and are the same considerations I have. Shipping with a pushbutton on/off is difficult since I have to cover the power switch to prevent the device from being powered up in the shipping and handling. I also made the decision to change to a slide switch, though I couldn’t find an SMD switch that met my requirements (4mm post, right angle) so I’ll be using through hole.
I also am concerned about charging in low temperatures. I disable charging in code when the internal temperature falls below 0C, and if the device charged while in a disabled state, it could potentially cause an unsafe condition.
I think you’ve validated what I was thinking. I think I’ll leave the TPL5010 in this next revision, and leave it connected to EN rather than RESET so that it can power cycle the modem with the rest of the board.
This is one of the things I was going to play with when I get the next board rev back. For example, with the diode in place, I would think that a large bypass cap could power the watchdog for some time.
Did not have use a diode in VCC. Added a 4K7 (I2C pullup) on SDA(D0) and on SCL(D2) - and 100K on !RST (pin 1)
Used UNO as a programmer - loaded your code above to '85 with one change - moved uC reset from D2 to D1 and it flashed and ran perfectly at 5V. Then put in level translation to 3V3 (ran '85 at 3V3) - all pull-ups in place and again flashed fine and ran ok
So it seems the I2C pull-ups have no affect nor does the !RST 100K.
@chipmc - seeing as the '85 can run as low as 1,8V (ATtiny85V) - why not run it from the LiPo with an LDO (something like MIC5504-2.8YM5-TR) this was you can drop ENABLE on the GEN3 without any issues and know that your timing periods will work as you have enough LiPo to run the '85 or the power reset cycle.
The other benefit is that if you connect the '85 PB1 to the EN pin you also pull power from any peripheral sensors driven by the GEN3 3V3 line, thereby resetting them as well which means you get a true cold start. So I like this option more and more …
It may need a resistor divider on done(PB4) pin to limit voltage from GEN3 (max Vpin input is VCC +0,5V and with a 2V8 supply it is exactly on max…).
Excellent recommendation - helps with the power consumption of the watchdog as well. I currently have a switch for power so, you could switch off the device manually for storage or shipment.
The one issue I can see is that this process would preclude us from connecting the watchdog to i2c for programming the interval. I thought this was an important feature for you?
at85_wdEN -> GEN3 ENABLE
at85_wdEN <- GEN3 I/O to ‘pat the dog’
SCL <-> GEN3 SCL
SDA <-> GEN3 SDA
It will mean that you will have to have some size of LiPo (even the minimum recommended capacity) for this to work but I think its a fair trade off for a customisable and reliable WDT
OK, one question: If this ATTINY85 is running at 2.8V but the SCL and SDA pins are pulled up to 3.3V - is this an issue? Never tried mixing voltages like this w/o a level converter.
Also, what if there is a simpler approach? If the bypass cap (currently an 0805) was replaced with a 1206 pad, you could put in a 11mF super cap like this one. Worth testing at least. If I got the inputs right in this supercap runtime calculator (warning not not a secure HTTPs site), it can go 30 seconds easily. Note, this approach has the downside of higher power usage as the ATTINY will run at 3.3 vs 2.8V like yours will.
Thank you for continuing to help improve this design!
So, I will start playing with the board from OSHPark and then we can share notes.
So if I look at the '85 spec - the IO pins can tolerate VCC + 0,5V = 3v3. However based on the effective LiPo cut-off voltage - I may as well use a 3v3 LDO instead since the LiPo SoC is almost 0% below 3V7 and this would be enough to make it work that low - will test and let you know what I find. Another factor is the Supercap = $0.69 vs the LDO = $0.12 and you always have a LiPo in the Boron based systems anyway - so I have updated the circuit…
Makes sense. I have a small concern as not all my deployed Borons have batteries but, this still looks like the best solution. Will do some testing on my end and I look forward to hearing about your results.
Thanks again for encouraging me to go down the ATTINY path. It is clear now that this will make for a better design. I was already thinking about the following use case which is enabled by the i2c connectivity:
Day mode - 1 hour watchdog periodicity aligning with the wake / report cycle
Critical operation mode - for example when I am controlling a pump - move to 1 minute or shorter cycles
Night time mode - In cases where the device sleeps through the night, the watchdog could be set to an 8 hour cycle.
I have started some code already and have found an I2C library I like that is simple and supports callback for onRequest() and onReceive(). I am also using the EEPROM to store the set values with a magic byte so that on startup it has its last values or defaults if its the first time.
I have started to build the next revision of the carrier board. Physical build went ver well:
I like the Qwiic style JST connectors - very dense
The new switch is eminently switchable - unlike my last choice
I think I can add more connections - perhaps a SPI header?
The holes on the Boron align exactly with the holes in the carrier. Too bad I cannot find an 18mm M2.5 nylon screw to put in. It is not my fault but, the Boron physical design does not give enough space between the pins and the mounting holes on the Boron to use a standard 15mm standoff - bummer.
Don't know why I didn't think of this earlier - seeing as the switch will be seldom used (If I understand your use case correctly) - then you could use a 3 pin header and bridging link something like
Pretty cheap and very deliberate action to switch so cannot switch in transit or when setting the system up.
Excellent suggestion. My use case requires park rangers to operate this switch (albeit infrequently / ideally only once) so, I need something simple with no prospect of losing parts. If I was doing the installs, I would certainly consider the jumper idea.
)
