LFCLK related issues in SDK14 DFU

[m.wagner]

In SDK13, the initialisation of the low frequency clock used to be done within sd_softdevice_enable. In the SDK14 version of nrf_dfu.c, the LF-clock is already initialized in nrf_dfu_init before the softdevice is started.

1. It would make sense to start the LF-clock before the SoftDevice is started if the function clock_init would call __WFE within the loop where it waits for the LF-clock to start. If the bootloader is busy waiting there, what is the reason to initialize the LF-clock separately?

2. Why is the LF-Clock initialised immediately within nrf_dfu_init? At this point it is not clear whether the LF-Clock will actually be needed. Especially if using an LF crystal, it takes very long until it is started/stable. I feel, it would be better if the clock would only be started after it is clear, that the LF-Clock must be started, i.e. after the check on line 188:

   if (enter_bootloader_mode != 0 || !nrf_dfu_app_is_valid())

   Is there a reason for the clocks to be initialised before this check?

3. Before the application is started (nrf_bootloader_app_start), the LF clock will be stopped again from within nrf_drv_clock_uninit. Why is the clock being stopped here?

   I do have two issues with this clock deinitialisation:

   • If a crystal oscillator is used, the clock will have to be started again from within the application, which would be costly in terms of time and therefore power consumption.

• With the RC-oscillator, I do have an issue where the bootloader hangs infinitely when waiting for the LF-Clock state to change to NotRunning. This seems to depend on the application that was running before the bootloader is started, i.e. it does not seem to hang e.g. with the ble_template example (modified to use an RC-oscillator), but it does seem to be an issue with my application. I did not find out what is happening here, though.

I would be glad if you could answer the above three questions, and if you could help me find out why the bootloader hangs inifinitely in a while (nrf_clock_lf_is_running())-loop depending on the application programmed.

[Thomas]

Sure thing. we're sending it your way (via email, we can't expose the firmware publicly).

For info we will send you: 0- flash memory content of the chip 1- hex file with a debug bootloader 2- hex file with a production bootloader 3- signed firmware with logs activated

the softdevice we used is s132_nrf52_5.0.0_softdevice.hex

The hardware does not have any low frequency crystal and is setup to use the RC instead. Our low frequency source is setup per recommended values (in sdk_config): NRF_SDH_CLOCK_LF_SRC 0 NRF_SDH_CLOCK_LF_RC_CTIV 16 NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2

the firmware works on: -DEV board (with RC as LF clock source) -PCB with a SIP that has a LF crystal (with RC as LF clock source, not the LF crystal)

the firmware does NOT work on: -PCB with a SIP package that has no LF crystal (with RC as LF clock source).

The problem manifests itself 95% of the time, but not 100%.