LFCLK related issues in SDK14 DFU

RE: LFCLK related issues in SDK14 DFU

Thomas — Mon, 27 Nov 2017 16:44:02 GMT

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.

RE: LFCLK related issues in SDK14 DFU

Thomas — Fri, 24 Nov 2017 16:05:11 GMT

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

RE: LFCLK related issues in SDK14 DFU

Hung Bui — Fri, 24 Nov 2017 12:32:56 GMT

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 ?

RE: LFCLK related issues in SDK14 DFU

Thomas — Fri, 24 Nov 2017 03:31:06 GMT

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.

RE: LFCLK related issues in SDK14 DFU

Hung Bui — Thu, 23 Nov 2017 13:57:06 GMT

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.

RE: LFCLK related issues in SDK14 DFU

m.wagner — Thu, 23 Nov 2017 12:49:44 GMT

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.

RE: LFCLK related issues in SDK14 DFU

Hung Bui — Wed, 15 Nov 2017 09:36:05 GMT

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.

RE: LFCLK related issues in SDK14 DFU

m.wagner — Tue, 14 Nov 2017 13:30:23 GMT

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

RE: LFCLK related issues in SDK14 DFU

Hung Bui — Fri, 10 Nov 2017 11:23:41 GMT

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

RE: LFCLK related issues in SDK14 DFU

m.wagner — Thu, 09 Nov 2017 08:52:50 GMT

@Hung Bui: Any news on this?

RE: LFCLK related issues in SDK14 DFU

Hung Bui — Tue, 31 Oct 2017 14:45:05 GMT

Hi m.wanger,

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