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]

Reporting good news: the reason why the LF-clock was not starting was that there was a mismatch between the hardware and the sdk_config. Since we have hardware both with and without LF-crystal AND it's not possible to specify this in the board files, we ended up leaving a LF_SRC to crystal when there was none. The bug only shows upon reboot after a OTA DFU since it's at that point that the soft device tries to stop and start clocks. The stopping never works if there is no hardware LF crystal. the baffling part was that it worked fine until then, so it looks like something that should be detected at compile time. Maybe add a #define in the board file so that if the hardware does not have a crystal, a misconfiguration in the sdk_config would not compile.

Hope this helps others.