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.

[m.wagner]

Sorry, once again, I clicked on "convert to answer" when I wanted to add a comment... This should probably be converted back to a comment.

Unfortunately I haven't come around to reproducing the issue in a little example yet. I'll try to follow it up ASAP.

[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.

[Thomas]

this answers question 1,2 and the first part of question 3. What about question 3 with RC? This seems to be happening to us. I'll try to get a trace or something more than "it hangs" but we do have an extra info about it: when one uses JLinkExe to connect to the board while it's waiting for NotRunning to change, the program actually starts.

PS: @m.wagner, if you have seen similar behaviors, feel free to chime in.

[Hung Bui]

Hi Thomas, we need to be able to reproduce the issue here to answer your question. Could you profile a minimum application that can reproduce the issue ?

[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%.