[NRF52] Internal Clock without Crystal

[Felipe Ribas]

Hi,

I had a problem with my NRF52 chips. I'm using one BL652 (Laird) with SoftDevice s132 (4.0.2) and a standalone nRF52832 also with the same SoftDevice. I was trying to Communicate them via UART. The BL652 module has Radio+Crystal (Ext Osc) and the standalone chip doesn't have none of them. Even though they both used internal clock source, the communication always had frame errors.

After running some tests with manual UART implementation, we realized that the baudrate had a difference between the chips (about 30%) even though they were both set the same baudrate via code.

The problem was only solved when we soldered an external crystal next to the standalone chip. Even though we still use the internal osc, now the frames are correct (after the crystal insertion).

Is there anything wrong with using the internal oscillator (without external crystal) even though the serial communication doesn't use high frequency? Is it mandatory to use external crystal even when using internal oscillator?

I know the datasheet suggests that the external crystal should be used to calibrate the internal osc, but I was wondering how to use the internal osc without the crystal.

Thanks

[AmbystomaLabs]

All communications on the nRF are based on HFCLK. I don't believe anything is so slow that it can use the LFCLK.

The only calibration mechanism the SD has is for the internal RTC. The RTC is mainly a sleep/wake clock and the calibration is required to meet a +/-250ppm spec for bluetooth. It also drives the app_timer.

There is no calibration mechanism for HFINT. If you are using HFINT for the uart your baudrate will be off. This is noted in the datasheet pg 338. "Baud rate. Accuracy depends on the HFCLK source selected." HFINT is not that accurate. That is noted a few times in the spec. It's main purpose is to provide a lower power solution for clocking the processor when things are not that time critical. That is why the SD won't run on HFINT it will only run on HFEXT.

Actually I am surprised you got the SD to start without an external 32MHz. I thought the code prevented you from doing that.

The external HF clock is critical for data timing and more critical to keep the bluetooth radio on the correct frequency. All the 2.4GHz channels are derived from the 32MHz crystal. So the ppm accuracy of the xtal will be the same ppm accuracy of your carrier in the 2.4GHz band. You may find your data connection problems are due to the bluetooth radio being off channel if it is indeed running on HFINT.

Hope that answers your question.

[AmbystomaLabs]

Ok, so just to clarify you have 2 nRF's one is in a BL652 using bluetooth and the other does not use bluetooth and does not have an external 32MHz but they communicate to each other via wired UART? And, further since the second nRF doesn't have a 32MHz xtal the UART baudrate can be plus or minus a bit. Correct?

I think you will always have issues getting UART comms to work under that scenario. You can try using flow control and also slowing down the data rate. This will improve the situation. But with UART comms there is no shared clock so the accuracy of either end is influenced by the relative clock differences.

If I had to choose I would probably use a communication method that uses a clock master such as SPI. You can do megabit data rates with SPI but the range isn't as great as UART or especially RS232 if you are using a level shifter for 232 comms.