[NRF52] Internal Clock without Crystal

RE: [NRF52] Internal Clock without Crystal

AmbystomaLabs — Tue, 20 Jun 2017 22:46:07 GMT

If you can figure out what the nominal offset is for your HFINT, you could choose a baudrate that is a little closer to reality. So, if your 32MHz is 25% slow you could choose a rate 1/.75 (33.3% faster). There is a little granularity on the enumerations for baud rate on the UART drivers. It is not all 2x. Plus it looks like they are just setting a register for a divider. So, with a little research you might be able to make the nRF do fractional rates.

But, ideally you should place the 32MHz next time. It'll save a lot of headaches.

RE: [NRF52] Internal Clock without Crystal

AmbystomaLabs — Tue, 20 Jun 2017 19:38:25 GMT

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.

RE: [NRF52] Internal Clock without Crystal

Felipe Ribas — Tue, 20 Jun 2017 17:31:59 GMT

Thanks for your answer. I posted here some comment but I think I misunderstood you. I think I get it now. But one question remains: How to make a reliable UART communication (stable baudrate) without a crystal? Is that any chance I could achieve that?

RE: [NRF52] Internal Clock without Crystal

AmbystomaLabs — Tue, 20 Jun 2017 16:47:18 GMT

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.