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.

[Hung Bui]

I have some update from R&D team about your question. We use the clock not only for the softdevice but also for the timer. And the timer starts before the softdevice (I think) so that's why we initialize the LFCLK early. But I agree, it can be delayed after we check if we need to enter DFU mode or not. Calling __WFE inside the loop is a good idea.

The reason we disable the clock is that we want to give a clean state to the application before it start.