I’m in the process of designing a low power circuit for the imp004m but can’t find much guidance in the spec other than a reference to a “Low power 4uA sleep mode (with external load switch)”. The Designing Hardware with the imp004m webpage only calls for an Xtal for a low power circuit.
The imp004m spec states the PSU_ENABLE pin 24 is “active high when WiFi needs 2.7v+”. Would I be correct in assuming PSU_ENABLE provides the same functionality as the WLAN_POWER_EN pin 9 of the imp003? I’m not sure as the imp003 also has a PSU_EN which is an “External power supply enable” but the WLAN_POWER_EN is an “External power gate enable”. Same, same but different?
Mm, that’s a mistake in the docs - the sleep mode is higher than 4uA on the 004m (I suspect I copied & pasted that from 003).
The 004m’s wifi chip has a pretty low power sleep mode (ISTR around 4uA for the wifi part, plus a few uA for the STM32) so there’s no need for the load switch and indeed no place to put it.
PSU_ENABLE is to enable an external boost if you’re running from 2xAAs. This is the equivalent of BOOST_EN on the 003.
Cool, so the Xtal is the only external component required for low power operation? Are you able to recommend a suitable Xtal?
I currently use a gpio and code to drive the PS/SYNC pin of a TPS63001, it sounds like the PSU_ENABLE on the imp004m performs the same function. Can you please confirm.
Are you driving the pin to enable a high current mode? This is what the PSU_ENABLE is there for - you can’t reliably drive this from code because there are times your code won’t be running (eg during an OS update). The imp will drive this pin any time it wants to talk on wifi.
I don’t have a board to try this on to hand, but power consumption in deep sleep should be around 3.5uA (wifi chip) + 4.5uA (stm32 with RTC on) + whatever consumption your SPI flash has when inactive.
When idling with wifi disconnected and no peripherals enabled that require clocks (blinkup, UARTs, etc), you should be around 3.5uA (wifi chip) and 25uA (stm32 main) plus… I would guess the ~4.5uA for the RTC. Note that pin change handlers will still fire in this mode, as will imp.wakeup().
All those are at ~3.3v. If you run at lower voltages when sleeping then it could be less. When the new imp004m devboards arrive I’ll take actual (vs spec) numbers and post those.
I like the look of those low, low current draw while running code figures!
The typical current draw for the imp001 and imp002 with Wi-Fi power save mode enabled is 5mA. Are you able to provide typical Wi-Fi power save mode enabled current draw for the imp004m?
Currently seeing around 3-6mA for 004 with power save enabled, but this is without a 32kHz clock to the STM32 or wifi chip, and on a busy network.
With a 32kHz supply on the LPO_IN pin of the imp004m (not currently documented, or supported on the imp side) this should be able to go below 1mA on a quiet network. This is not supported on release 36 though, we’d need to add an option to configure pinE (pad 15 on the imp004m) as MCO 32kHz output and then you’d need to wire this to pad 13 (LPO_IN) on the module.
You can do the wiring now, though - with no clock on there it won’t behave any worse than it currently does.
1mA in power save mode? Yes please! I’ll wire pins 13 and 15 as recommended, in anticipation of the functionality being incorporated in a future release.
I’m curious, how does a 32kHz clock on LPO_IN cause the imp004m to draw less current in power save mode?
When in low power mode, the wifi chip turns off the main 38.4MHz oscillator when sleeping; it wakes this up (and the wifi receiver/mac) when it’s expecting to hear a beacon packet from the wifi AP.
If there is no 32kHz xtal available, the wifi chip will use an internal RC clock. As this is less accurate, it has to wake for longer to ensure that it’s awake when the (every 100ms) beacon is transmitted by the AP.
Essentially a clock allows the wifi chip to stay asleep for longer.
Tried on a 32kHz board; note this is a sample of 1!
imp004m breakout
imp004m ES3 (vaguely production accurate)
Adesto AT25SF081 flash
impOS 36.2
LDO removed, powered from external supply with keysight 34465A inline
Flash spec is 13uA typical in idle, and 2uA in deep power down mode. We do not (yet) enter deep power down mode in impOS, so assume 13uA is the flash in the numbers below.
In deep sleep:
seeing 20uA
With 13uA to flash that’s 7uA to the imp+wifi, which is pretty close to the 8uA typical spec.
In idle, disconnected from wifi
squirrel ready to run, but nothing actually going on
all GPIOs unconnected, and configured as DIGITAL_IN_PULLDOWN to reduce leakage
wifi disconnected with server.disconnect()
Seeing ~30-60uA depending on temperature, ie if I hit it with freeze spray it drops to 25uA)
Currently there are little peaks of 150-200uA every 15s, I think this is our stack checking kicking in - I’ve filed a bug about this.
In idle, wifi power save, connected to imp service (not a quiet network!)
squirrel ready to run, but nothing actually going on
all GPIOs unconnected, and configured as DIGITAL_IN_PULLDOWN to reduce leakage
wifi in powersave mode, no LPO connected… I believe we are in DTIM 1
averaging current over 1s
No 32kHz LPO (wifi sleeping on internal oscillator)
Seeing 1.5-4mA
If I connect a 32kHz LPO clock I get a little lower, maybe 1.2-3mA, but again this is on a busy network and I believe at DTIM 1, which is specced at 1mA average. DTIM 3 should take ~600uA off that, so we should be below 1mA on a quiet network.
The imp004 units we’ve been developing on, have shown very wide variation in power usage from device-to-device. The best one I’ve seen does about 9uA idle (wifi off), but many pull 20-40uA and one 150uA. There is also very wide variation with temperature, as Hugo notes. On the other hand, these were early samples and production ones might be closer-together.
From the imp004m preliminary spec, the CLK_REQ pin “Asserts CLK_REQ when WLAN directs the host to turn on the reference clock. The CLK_REQ polarity is active-high.”
Is the CLK_REQ used to turn on an external reference clock for the LPO pin?
No, we don’t use it, as that’d burn another pin. We will just give you the ability to turn on the MCO output - the power used by this is minimal.
If you were using an external LPO then yes you could use this pin to control it, though actually most of the MEMS ones are so low power they don’t even bother with an enable either, eg https://www.sitime.com/products/32-khz-oscillators/sit1533
Actually, sorry - CLK_REQ is for the reference clock (38.4MHz and internal to the module) not the sleep clock.
CLK_REQ will go up and down when the wifi chip is in low power sleep, but as it drives its own xtal it’s not going to super useful as an external signal. If it’s high then the device may be powered up, but if it’s low it doesn’t mean that the device is definitely not associated (ie, it could be in low power mode).
