IMP004 BLE & Low power

I’d need some clarification on the dependencies between Low-Power, 32kHz crystal, BLE and the ‘required’ connection of LPO_IN to PinE.

When not using/interested in Low Power mode but with a requirement of BLE enabled continuously (mains powered device):

  • do we need the 32kHz crystal or not ?
  • is the connection of LPO_IN to PinE required (burning a GPIO pin) or not ?
  • the design note makes a mentioning of certain operating mode not available in ImpOS 38-, but it’s not clear what is or isn’t available
  • can we just pull BT_REG_ON continously high, or do we need to do it via another GPIO (eg for a sequenced enabling of the BLE function) ?

Thx to clarify !

Any feedback ? We’re a bit stuck in our design process waiting for this info …

Sorry, didn’t notice this.

  • You do not need the 32k crystal, no
  • You should connect LPO_IN to a PWM capable pin (which doesn’t include pinE - this has no PWM)
  • BT_REG_ON should be connected to a GPIO so BLE can be power cycled as necessary

The guide “Using Bluetooth LE with the imp004m” explicitely says that LPO_IN needs to be connected to PinE…(in the description of which bridges to make on the breakout module).Is this an error in the guide, or is this the setup in case you use LP modes with the 32KHz crystal ?

There are two possible LPO_IN configurations; BLE always requires a 32kHz clock, but there are two alternative ways of supplying it.

Most designs should include a 32kHz crystal and connect pinE to LPO_IN:

For designs where low cost is so critical that you are prepared to put up with higher power consumption and missing deep-sleep modes, it’s intended that you’ll be able to instead connect one of the imp004’s PWM-capable pins to LPO_IN and omit the crystal.

We only came up with that second idea after the current version of the datasheet and guide were released; we’re working on releasing new versions which explain both alternatives. We’re also working on exactly how you (as a manufacturer) tell the imp which of those configurations it finds itself in.

Note that BLE support will be made available in improm 38.0; if you need to experiment with it before then, talk to us about getting on the 37.x beta programme.


OK, so after further discussions with our hardware department, it turns out that probably only unusually intensive use of Bluetooth requires the 32kHz clock. Many customers might be able to get away without it. We’re still in discussions with our silicon supplier about exactly what’s going on here, but for now the advice seems to be:

  • If your design already includes a 32kHz crystal, then you should wire pinE up to LPO_IN, just in case it’s needed.
  • Otherwise, you should wire one of the PWM-capable pins up to LPO_IN, just in case it’s needed.
  • Either way, that pin needs to be dedicated to LPO_IN, and can’t be used for anything else. If your design is so pin-constrained that you can’t spare a pin for LPO_IN, hang on for now and hopefully we’ll be able to provide more information by the time release-38 comes out.


Thanks Peter.
We can spare one more pin for the BLE functionality, but does the API already cater for it ? There’s nothing there now to tell the underlying code which pin has been assigned.
We’re anticipating using this BLE functionality in production from April or May onwards. I hope by then it’s available in the production releases…

One more question: On the IMP005, Hugo told me I could supply the 32kHz clock with a TTL level clock coming from another component (RTC PCF85263A with Crystal attached and 32kHZ clock out).
Is that also possible for the IMP004 ? If so, which input do we take (OSC32_IN or OSC32_OUT) ?

The not-unusually-intensive case should already work fine by default in release-37.12 and later, with no API calls (or NVRAM changes) required. All the mithering with LPO_IN is only relevant for use-cases which fall into the unusually-intensive category.

By the time release-38 comes out, I hope that we’ll have a more precise definition of “unusually intensive” – so that people in your position can determine whether they count or not – as well as information on the API calls and/or NVRAM changes that those customers will need to employ.

We haven’t tested clock-in mode on the imp004, but the STM32F412 reference manual (figure 14) says to feed the clock into OSC32_IN and leave OSC32_OUT disconnected. Out of interest, how come you’re using an external RTC and not the imp004 built-in one? Note that if we’re still talking about the same design, you could send the PCF85263A’s 32kHz output to both OSC32_IN and LPO_IN, and save yourself an imp004 pin.


Well, see my other questions of about a week ago on the IMP004 RTC. Still hoping I can eliminate the RTC but awaiting your expert advice :slightly_smiling_face:

If we would be using this TTL level clock output to feed OSC32_IN and LPO_IN, is it critical that the clock has a 50% duty cycle or not ? The RTC we’re anticipating using guarantees a 40-60% duty cycle, but not 50%.

The datasheet of the CYW43438 says acceptable duty cycle is 30-70% so you should be fine. Only needs to be 200ppm accuracy too.