Problem upgrading from SDK v15.3.0 to v15.0.0

[Greg Strange]

I’m working on a product that has been in the field and working for many years with nRF5 SDK v15.0.0 / softdevice 6.0.0. Now we want to add extended BLE advertisements and need to upgrade the SDK and softdevice. I have attemped to upgrade to v15.3.0 / SD 6.1.1, but when I do the firmware no longer runs.

If I step through the code with a debugger, it hangs after enabling the high-frequency clock (i.e. after calling hfclk_start()). If I break the code in the debugger, the PC is always at the clock IRQ handler (0x75A, from vector at 0x40). If I comment out the call to hfclk_start(), then I can continue to step through the code though of course things don’t run properly because I don’t have a clock. All of this same code works with SDK v15.3.0/SD 6.0.0.

I spent a good deal of time comparing changes to the sdk_config.h file examples from v15.0.0 to v15.3.0. The two changes I made were I had to change CLOCK_CONFIG_ENABLE to NRF_CLOCK_CONFIG_ENABLE and I changed the IRQ interrupt priorities from 7 to 6 to match the sample sdk_config.h changes. I also spent a good deal of time stepping through and comparing the nrfx_clock.c code that gets compiled for v15.0.0 and v15.3.0 and am convinced there are no differences once if added the NRF_CLOCK_CONFIG_ENABLE. I’ve kind of run out of ideas and looking for any help.

Thanks.

[Einar Thorsrud]

Hi Greg,

Is it the internal hfclk_start() in the clock driver (nrf_drv_clock.c) you refer to? If not, can you share the implementation? Can you say a bit more about what you do so that I better understand? Particularily which clock API you use and at which time (before or after initializing the SoftDevice). Has this changed as part of your porting to 15.3 so that a bug could have been introduced here? Also, have you done any changes to either of the SDKs itself? I am asking as I would not expect any difference here as long as you have updated the configuration defines.

Also, note that when the SoftDevice is enabled, that controls the HFXO, so for BLE there is no need to control it (whenever the radio is active, the HFXO will be on). Moreover, it is also not allowed to control directly once the SoftDevice is enabled, and that must be done via SoftDevice APIs. See Hardware peripherals. This means that the nrfx clock driver cannot be used, but the nrf_drv_clock can be used, as that use SoftDevice APIs when the SoftDevice is enabled.

PS: For most devices using the SoftDevice that is always running, and if so you can typically wait explicitly requesting the HFXO until after the SoftDevice has started, so that it always happens via the SoftDevice.

Einar