Using runtime started LFCLK external oscillator with nRF5340 and Bluetooth enabled

RE: Using runtime started LFCLK external oscillator with nRF5340 and Bluetooth enabled

Vidar Berg — Tue, 02 Apr 2024 06:36:17 GMT

You are right, there is a static build assert that will be triggered if you build the network firmware without clock calibration enabled. From a HW perspective, it does not matter whether the calibration is performed on the application core or the network core. However, in the SDK, we have decided that clock calibration should be performed by the network core when BT is enabled. I thought the calibration was done by the application core (this was true in earlier SDK versions), and therefore, it would be possible to trick the BT controller into using the RC source uncalibrated.

RE: Using runtime started LFCLK external oscillator with nRF5340 and Bluetooth enabled

Nathan — Wed, 27 Mar 2024 15:04:41 GMT

Using your register definitions in soc.h would probably be cleaner and I might switch to that later, it winds up being the same idea in the end though.

Earlier I tried setting that CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n value, but it gave me a build error in a zephyr driver. I've re-tested it now and it worked fine when setting only application and bootloader, until I stopped lying to the network core and told it to use RC clock with no calibration. Then the build error shows up in /subsys/mpsl/init/mpsl_init.c in the mpsl_calibration_work_handler function. That function only cares about the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC definition and always tries to grab CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_PERIOD, disrespecting the CALIBRATION=n setting. So network core needs to be lied to and reset after runtime clock config right now, but maybe starting on RC would work fine if only the application and bootloader were told to use it with the calibration disabled. I'll try testing that later when I get some time. In the meantime I don't think there would be any issues of just falling back to startup with SYNTH instead as long as you can stomach the extra power draw of leaving HFCLK on (in my case the bootloader is USB based so I don't care about power draw there, and init is short, so it's no issue).

In any case starting the network core on RC to prevent having to reset it is untenable due to the build error. And additionally that might be behavior that the SDK shouldn't change, because in literally any other situation the SDK should produce a build error if the user is trying to use Bluetooth with an uncalibrated RC clock. It just happens that in this unique case I need to start up on an alternate clock source and have no intentions of leaving the network core in a state where it's running on an uncalibrated RC by the time I go to start initializing the Bluetooth services over hci_rpmsg.

RE: Using runtime started LFCLK external oscillator with nRF5340 and Bluetooth enabled

Vidar Berg — Wed, 27 Mar 2024 14:26:10 GMT

I see. Generally, hardware specific initializations can be placed in your board files. However, getting a clean solution in this case might be difficult since configuration involves using the I2C bus. Technically, you could use the nRFx drivers directly for this, as they do not depend on the sysclock or other Zephyr resources. But I guess it might conflict with the actual initialization of the RTC later in the startup process.

[quote user="nproux"]For bypass, yes I had to resort to setting the bypass register directly while taking into account the base pointer difference between secure and non-secure application modes. I do this just before modifying the LFCLK source and kicking the start trigger. My code for that part looks basically like this:[/quote]

Thanks. I just wanted to make sure. You can also include soc.h an use our register defintitions.

E.g.,

NRF_OSCILLATORS_S->XOSC32KI.BYPASS = 
    (OSCILLATORS_XOSC32KI_BYPASS_BYPASS_Enabled << OSCILLATORS_XOSC32KI_BYPASS_BYPASS_Pos);

[quote user="nproux"] If there was a way to suppress periodic calibration of the RC clock then that would have been an option as well, given that you don't actually need regular calibration in this situation, but that would definitely require some changes to the SDK to become available as an option[/quote]

Did you try to build with CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n in your appcore FW?

RE: Using runtime started LFCLK external oscillator with nRF5340 and Bluetooth enabled

Nathan — Wed, 27 Mar 2024 13:56:17 GMT

It is probably possible to start the external clock pre-kernel in many cases. There's just no general way to do it that could be added to the SDK files because what's actually required to start up your external clock is heavily dependent on your exact hardware setup. Mine for example needs both a GPIO write to bring up power to the oscillator, plus some extra I2C serial transactions to set it to the correct speed. Others might just be started up automatically with board power and never need a manual kickoff. The limitation when doing it pre-kernel is that you can't use any resources that rely on LFCLK to be running as part of your external oscillator startup procedure, and if you do need those resources then your only option is to start up on SYNTH and do a manual switchover later. If there was a way to suppress periodic calibration of the RC clock then that would have been an option as well, given that you don't actually need regular calibration in this situation, but that would definitely require some changes to the SDK to become available as an option.

For bypass, yes I had to resort to setting the bypass register directly while taking into account the base pointer difference between secure and non-secure application modes. I do this just before modifying the LFCLK source and kicking the start trigger. My code for that part looks basically like this:

// Set address of registers based on secure vs non-secure application mode
#if APP_NS
static const uint32_t oscillators_base_addr = 0x40004000;
static const uint32_t oscillators_bypass_offset_addr = 0x6C0;
static const uint32_t oscillators_bypass_enable = 0x1;
#else
static const uint32_t oscillators_base_addr = 0x50004000;
static const uint32_t oscillators_bypass_offset_addr = 0x6C0;
static const uint32_t oscillators_bypass_enable = 0x1;
#endif

// Set bypass to use "oscillator mode" instead of "crystal mode" on external pin
uint32_t volatile *p_osc_bypass_reg = (uint32_t volatile *)(oscillators_base_addr + oscillators_bypass_offset_addr);
*p_osc_bypass_reg = oscillators_bypass_enable;
__DMB();
__DSB();

RE: Using runtime started LFCLK external oscillator with nRF5340 and Bluetooth enabled

Vidar Berg — Wed, 27 Mar 2024 12:53:07 GMT

Hello,

Thank you for the detailed write-up. I'm wondering if it would be possible to initiate the external clock source before the pre-kernel initialization here: https://github.com/nrfconnect/sdk-zephyr/blob/272786b074227b4abcbe8f954d5bb8acf54f3dd3/drivers/timer/nrf_rtc_timer.c#L771 which is requesting the LF clock.

[quote user=""]You'll of course need to make sure that the low frequency external oscillator is connected to the XL1 pin as usual, and that XL2 is left floating. [/quote]

For the nRF52 series we had the following Kconfig symbols to enable support for external clock source in the clock driver: https://github.com/nrfconnect/sdk-zephyr/blob/272786b074227b4abcbe8f954d5bb8acf54f3dd3/drivers/clock_control/Kconfig.nrf#L45. Support for the nRF53 does not appear to have been added yet.

Did you set the bypass register directly?

Low-frequency (32.768 kHz) crystal oscillator (LFXO)

Best regards,

Vidar