NRF_SDH_CLOCK_LF_SRC Changes Break app and DFU in 15.3 (from 15.2)

[dmacpro91]

I've finally worked around some funky bugs that only appeared after updating to 15.3. In my app, I had to change my clock source to RC or SYNTH to make it work (was hanging on enabling the softdevice). My XTAL setting worked fine in 15.2. When I got to working with DFU, I had some issues and tried everything mentioned on here (mergehex to fix the UICR/MBR bug, fixing the Makefile, etc.), but still couldn't get the DFUTarg device to appear. Loaded the debug version of the DFU module and stepped through it to find it failed to execute past the command to start the softdevice. It dawned on that this was probably the same issue that prevented my app from executing. After changing the clock source, everything worked as expected.

Now my question: What changed that makes the XTAL clock setting work fine in 15.2, but not 15.3? I'm using the DVK-BL652-SA device from Laird. Is there any issue using the SYNTH clock setting if power consumption isn't really a concern?

[dmacpro91]

The problem appears even when I'm just working with the stock 15.3 dfu/secure_bootloader example (not bothering with my custom application at all).  I simply duplicate the 15.3 dfu/secure_bootloader example, open the duplicated project (pca10040_ble/ses), add in my public key file, build, debug, and then it hangs on enabling the softdevice.

[Simonr]

Hi

This seems very strange. How do you confirm that it hangs in enabling the SoftDevice? Have you checked if the SD_BLE_ENABLE returns successfully? Have you tried erasing the flash memory on the nRF completely and just flash the chip with the Bootloader and SoftDevice, to make sure the application itself isn't causing any conflicts?

You could also try testing this on another chip, to see if it reproduces on another HW (this is a long shot though) to confirm that the problem is in the software. We've used the SDK 15.3 version of the secure bootloader multiple times here at the office without seeing this issue, so there shouldn't be a problem with the example itself.

Best regards,

Simon