nRF52832 external crystals needed or not

[Mattias]

Hello,

I need some clarifications about external crystals for nRF52832.

We are evaluating a prototype system with two units A and B each containing an nRF52832. A and B will communicate via UART. Unit A will also use BLE to communicate with other units. Unit A shall wake up on RTC every 10 ms to check if UART is connected to unit B.
Unit B are powered from unit A so will be an POR every time unit A is connected.

1. Unit A needs a 32 MHz crystal since it will use BLE, correct?
2. Unit A needs a 32 kHz crystal for the RTC wakeup, correct?
3. We don't need a 32 kHz crystal for unit B, correct?
4. Do we need a 32 MHz crystal for unit B? According to the answer here we don't need a crystal at all since we are not using BLE but according to the design guide lines found here the 32 MHz crystal is mandatory on nRF52832. I know the question in the first link is about nRF51 but the answer indicates that nRF52/nRF51 works in the same way.

The main reason to exclude crystals in unit B is to save space.

Thanks in advance, Mattias

[endnode]

Hi Mattias,

There are like dozens of similar questions on the forum but let's go through it again;)

1. You always need external HF clock source on nRF52, no exceptions (more about that in last point).
2. You don't need to have LF external clock source but then you are either on "power hungry and not officially supported for Nordic BLE stack" synthesized clock from HF or on internal RC which need some SW routine to periodically calibrate. There are many hints on infocenter and this dev zone about this so it should be still safe way.
3. The same as previous point.
4. I believe that running nRF52 on internal HF clock (which is normally used only before external 32MHz crystal is stable and can be used) is highly not recommended. You can probably run nRF2 on it but that means you cannot use radio which brings the question: why would anyone on Earth use chip dedicated for BLE for something else when any general purpose ARM Cortex-M MCU can be used instead?;) Just with STM32 product line you get cheaper, smaller, more power effective (when you don't need 2.4GHz radio) and smaller PCB footprint items, similar with other vendors...

Cheers Jan

[Mattias]

Thanks! I understand your comment about using a general purpose MCU. If the configuration in the final product will be as I described in my question this will probably be the case. At the moment we are in an early concept evaluation phase and want a prototype that can support different configurations with minor changes (e.g. add crystal and support BLE in unit B).