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 ?
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.
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%.
