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]

Hi m.wanger,

Your questions make sense. I have sent the questions to our developers. We will get back to you soon.

[m.wagner]

@Hung Bui: Any news on this?

[Hung Bui]

Hi Wagner,

My apology but I still haven't got the response back from the author of the library about the change he made. Just pinged him again.

Regarding your issue, have you made sure you stopped all peripherals before you switch to the bootloader ? And how did you jump to bootloader ? by a soft reset or you branch directly ? A soft reset is recommended. And if a softreset is used, I see no reason why the previous application would affect the bootloader.

Hung

[m.wagner]

Hi Hung,

No, there is no code specifically switching off any peripherals. The bootloader is entered using a soft reset (issued through sd_nvic_SystemReset() or using the Keil debugger RST).

The issue seems quite strange, therefore I'm happy for any pointers here. I did work around the issue for now by patching the bootloader to not disable the LF-clock before starting the application. I'd still be grateful for an official response!

Thanks, -mike

[Hung Bui]

Hi m.wagner,

If possible, could you provide us an example that can reproduce the issue you mentioned about the RC oscillator ? if you aren't sure what trigger the problem, you can use simplify your application, so that we can test on the DK here.