Techn, thanks for the idea. The consumption is probably for internal RC (low precision) so need to check what external osc adds. Also, there's probably no dedicated clock out, so this would mean bit-banging a clock in ASM. It's probably deterministic (an 8bit micro is actually quite good for real-time), but feels a bit wonky. Still, an option.
Jan,
> HSE bypass does not consume anything, but the external oscillator does, and it will be in the 150uA ballpark.
There's been some confusion already about terms, so let's be precise. Oscillator/Resonator/Crystal - to me those terms indicate that you need to involve the STM32 internal circuits in order to care and feed them and the power consumption is punitive. As you know, HSE bypass requires an external *clock*, i.e. a single-sided square-wave signal of reasonable duty-cycle, generated externally.
I'd be very happy with any IC or circuit that can generate a 1Mhz *Clock* with crystal (rather than RC-constant) accuracy,
and consumes 150uA. If you're able to suggest a part number, please do.
The reason I'm so set on HSE bypass and using an external clock, is that the power estimator claims dramatic power reduction (even including the 100-200uA an external clock would/should/hopefully might consume).
In particular, the power estimator says that HSI16 (or indirectly via the circuitry involved in employing it) would consumes roughly 600uA in my design, and not 150uA as you suggest (based on the DS). See shots below. It's possible the estimator is simply wrong for this corner case. Are you saying I should disregard it as a a bug? It possible the oscillator circuitry's power consumption scales with the frequency of the source. Since the HSI16 input is 16Mhz, even if I divide it later, I still pay the cost at the clock input. I could be wrong.
Another concern is that if I'm to avoid the PLL, I can only divide the HSI16 down to 1Mhz or 250Khz for HCLK due to the limited divider ratios (/16,/64) available. Since my design can run at 400Khz, running at 1Mhz would be wasteful.
So why not just try with HSE crystal, 4MHz , and check real world value then ?
Or with hse-bypass, maybe the lowest possible consumption (if no crystal precision needed) :
584-C6930IMS88.00TPF (mouser)
So you can expect about 150uA at 1MHz setting for this kind of micro-power-osc.
I thought the power estimator must be backed up by numbers in the datasheet, and so I checked:
As you can see, power consumption is much lower for HSE Bypass than when using the internal HSI16.
Furthermore, although I can't find an explicit statement to this effect in the datasheet, for LP-run/Sleep modes the power estimator only accepts HSI or HSE Bypass(i.e. external clock) as sources. That suggests to me that using an external crystal in those modes is not even possible. It's divided HSI or external clock only. I could be wrong. (Update: Indeed I was wrong. ST rep confirms HSE crystal can be used in Low power mode. But the circuits supporting an external crystal itself consume appreciable power)
And yes, I've considered switching to U5, but the G4 has more analog peripherals which I might want to use.
EDIT:
Of the register bit which enables Low-power mode, the RM only states that the clock needs to be no faster than 2Mhz. The Current consumption tables only include fHSE (which I'm assuming is Bypass, since an earlier table claims all clks<48Mhz use HSE Bypass) and HSI as sources. But, the HAL code for switching on LP mode simply flips the bit. It does no checks, and there is no error condition/panic I can detect when I used a <2Mhz clock based on an HSE crystal, so I'm not sure what's going on there and what's the power consumption compared to the above table. A different possibility is that LP modes support an HSE crystal, and HSE Bypass is not mandatoty but, for some reason, HSI16 in LP mode consumes 3x times as much power as using an external crystal. This is all very confusing. Is there no Bat-Signal mechanism to get ST to clarify??
