Hi,
Setup:
nRF NCS 1.9.x and nRF NCS 2.5.0
nRF5340 and nRF52840 both with an external crystal attached to HF clock input.
Problem:
Inaccuracy in timing of UART at baud 115200, seems like the 2X nRF chips in my setup have difficulty talking to one another as the temperature rises. The suspicion being that the internal clock (HF) varies enough in timing and that causes enough delta that makes the bits uninterpretable for the receiver. I am reading that baud 115200 requires timing within +-2%. I can see through scope captures that the duty cycle of each bit does vary more than that at high temp. So hence the suspicion.
Through a lot of reading I've realized that the HF internal clock is not very accurate, thankfully we have a +-20ppm TCXO attached to the chip. I understand that the chip turns on that clock source and switches to it automatically during BLE transactions (is it when connected only? Or advertising too?) - I want this expanded to whenever UART RX/TX is happening.
How do I configure a UART that's mapped to an mcumgr interface to use the TCXO for more accurate timing?
I see some examples that directly call into clock management API (at_client sample of nRF9160), but that then requires manually calling to enable the external clock, then do I have to shut it down manually also? Doesn't sound very elegant and Zephyr'y. But if this is the only way, any further guidance would be appreciated.
Ideally there'd be way to directly configure the UART in the dts file that this UART requires HFCLK to use external source. Is this supported?
2nd: can I confirm through enabling some debug info, that indeed the UART receiver is having framing or timing errors? Is there a way to propagate the UART peripheral's events up to the app in some sort of a LOG_INF/WRN? The CONFIG_UART_LOG_LEVEL had very little and only ERRs.
Thanks,
