Boron / Argon - Using the Enable Pin for Sleep with a Real Time Clock

Hardware
1

I have been testing my carrier board with Enable sleep and I have not achieved the results I was hoping for.

The good news is that I can achieve very low power consumption (less than 1mA, I need to get my uCurrent back from a friend to be more precise).

The bad news is that I am seeing two problems which may be related.

  1. Periodically, using the Enable pin for sleep occasionally puts the Boron into a state where it no longer allows the battery to be charged:
    Battery Charge doesn't work if starting when EN grounded
    Boron Devices Stop Charging deviceOS@1.5.0
  2. Occasionally, the Boron will not wake even when the Enable pin is no longer grounded.

I am wondering if we could capture in this thread the right design requirements for using the Enable pin as I have looked across the forum and found conflicting advice. Some questions include:

  • What voltages will the Enable pin tolerate? As it shuts off the 3.3V supply from the Boron it is tempting to power the RTC interrupt pin with voltage directly from the LiPo which goes to 4.2V. If I have the right data sheet voltages up to 5.5V should be OK. There are two series with different characteristics so not sure what the answer is here.
  • What type of considerations are there for the pull up and voltages that drive the Enable pin. It seems it is pulled up to 3.3V. What happens when we apply 4.2V from our RTC interrupt pull up?
    24c93d6235231be731f22f37d84c925f2bcdd996_2_236x250
  • What are the values of logic high and logic low for the Enable pin?

Here is the circuit I am using now using the MCP79410 clock and @rickkas7’s library. Do I need to put a MOSFET between the Enable pin and the RTC so it does not see voltage higher than 3.3V?

Screen Shot 2020-05-14 at 2.16.36 PM
Screen Shot 2020-05-14 at 2.16.36 PM826×604 4.62 KB

  • Are there conditions that could cause the Boron not to come back on even if EN is high?

Any advice is appreciated.

Thanks,

Chip

1 Like
2

Chip, on my first EN Pin trial, the Boron LTE performed 10,000 successful connection cycles using the EN Pin. That was accomplished with the TPL5111, which pulled the EN pin UP to the Li+ Voltage (but using a primary pack). That's a 5.4 OCV at the beginning of the trial with no issues.

3

@Rftop,

Thank you so, it does not seem that LiPo voltage should be an issue. As for 10,000 cycles, I am not seeing that kind of reliability so, there may be some additional factors at play here:

  1. I am pulling the EN line low using the INT pin on the RTC - it may not be doing this well enough as I noticed that the voltage does not go to zero (0.360V).
  2. The RTC is an i2c device and I wonder if there is some issue in the i2c bus locking up - especially if the EN line is not brought up smoothly.
  3. My device needs to connect once it wakes, perhaps there is an issue with the modem coming on-line.

I think I might try your idea or getting a chip to cycle the EN line and then try turning on different blocks of code to see what makes it less reliable.

Thanks,

Chip

4

This reminds me of a problem I had a few years back with a Photon in a board with I2C devices trying to get it to sleep reliably and at the necessary very low current level (hibernation). The root issue (and I don't know if this is the same for your board) was that voltage was being sourced (or sinked) from an I2C device via SCL or SDA lines. This meant a switched bus to turn off such ICs had to be implemented with careful selection of mosFET and resistors. I couldn't see in the schematic above any pull-up resistors or how you decouple the powered MCP79410. It maybe that keeping the IC on whilst having an I2C connection to the Boron is not possible and that might be why the TPL5111or equivalent is the way to go.

5

@armor,

First of all, somehow I missed your post otherwise I would have replied earlier. I had not thought about this possibility but you raise a very good point.

Here is what happens when the Enable pin is taken low:

  • The Boron is shut off and Vcc goes to zero
  • The i2c devices are also shut off as they are powered by Vcc
  • The MCP79410 goes into low power mode running off VBat

My understanding is that when the low power mode, the MCP7940 is not communicating over i2c and can only raise the INT line (connected to Enable) when the alarm sounds. From the data sheet (page 33):

The MCP7941X features a backup power supply input
(VBAT) that can be used to provide power to the
timekeeping circuitry, RTCC registers, and SRAM while
primary power is unavailable. The MCP7941X will
automatically switch to backup power when VCC falls
below VTRIP, and back to VCC when it is above VTRIP.
The VBATEN bit must be set to enable the VBAT input.
The following functionality is maintained while
operating on backup power:

  • Timekeeping
  • Alarms
  • Alarm Output
  • Digital Trimming
  • RTCC Register and SRAM Contents

The following features are not available while operating
on backup power:

  • I2C Communication
  • Square Wave Clock Output
  • General Purpose Output

Given this is the case, I don't see how power could be sourced or sinked from the i2c lines. Sill, until I figure this out, I will keep this possibility in mind.

Thanks,

Chip

6

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.