Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application

[denis]

I have an existing product that is using the nRF5 SDK 17.1.0 Bootloader.  I have updated the application to use nRF Connect SDK 2.1.0.  The new application also has an implementation of the buttonless DFU service, so that the nRF Connect app on iOS can be used to do the updates.

Most of this is working.  The application runs fine when built to run without a boot loader.  When build to run with the boot loader (CONFIG_FLASH_LOAD_OFFSET=0x27000) there is an issue that I'm having trouble debugging.  This is what is happening:

1. I erase the device and program in the nRF5 SDK 17.1.0 Bootloader.  After reset the boot loader starts up normally.
2. I use the nRF Connect app on iOS to transfer over the nRF Connect SDK 2.1.0 application.  I get a success message from the nRF Connect app.
3. The application does not start BLE advertising and the device appears to be hung.
4. If I attach the VScode debugger, it usually halts inside the boot loader startup sequence where it is checking the CRC.
5. Looking at the RESETREAS register I see the expected SREQ, but I also see LOCKUP.
6. If I continue code execution then the application starts up and works fine.

The hang happens every time I run the above sequence.  It happens with or without a debug probe attached.  None of the nrfjprog resets (--reset, --debugreset, --pinreset) have any effect - the device remains hung.  If I attach the debugger before step 2 above then the halt doesn't happen.  The application starts up fine without any hang.

Anyone have any ideas on what might be happening?  Any tips on how to debug this type of issue where simply having the debugger attached avoids the issue?

[Vidar Berg]

Thank you for the summary. I'm glad to hear that you found the problem!

denis said:

Thank you for all the help!  Obviously I should have seen this when setting up the custom dts.  What I still don't understand is how that manifested in all these other odd things happening, working from the debugger, etc...

It must be because of the noise generated by the DCDC. Although, I'm not able to explain exactly how this would interfere with the clock startup. This does however explain why you didn't experience the problem when the chip was in Debug Interface mode as this mode forces the chip to switch to the LDO regulator.

denis said:

I don't have a storage partition defined in my custom board dts that my app uses.

The build should fail at compile time if there is no storage partition defined. This is also what I observe here if I remove the storage_partition node before building the LBS sample.

I would suggest that you check the generated zephyr.dts file in <build directory>/zephyr/ before adding the overlay to see if the storage partition is indeed missing.

[denis]

Ah, so the switch to LDO when attaching the debugger explains why the firmware works after the attach.

BTW: The peripheral_lbs build does fail with my custom dts.  I built it for the nRF52840-DK and ran that on my custom board as it is somewhat compatible, at least for that simple example.