This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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?

Parents
  • 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

Reply
  • 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

Children
No Data
Related