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?

[denis]

I am trying to use a simpler app to see if it will start properly, so I am now using the sample hello_world.  It is showing the same issue.  However, this time when I attach in the debugger I end up in the same place each time - inside lfclk_spinwait loop:

while (!(nrfx_clock_is_running(d, (void *)&type)

... k_cpu_atomic_idle(key);

If I hit continue in the debugger then hello_world starts up.  So maybe some issue starting up the low frequency clock or getting the interrupt that it has started?

This issue does not happen when an SDK 17 app is DFU'ed.  So maybe something different in the Zephyr startup sequence with respect to the low frequency clock startup?

[denis]

It is in the application address range.

[Vidar Berg]

I wish I could reproduce this here. Could you try the peripheral_lbs app I included in my first reply here to see if it results in the same problem? I included a pre-built hex for it (ncs_app.hex).

[denis]

I built peripheral_lbs with these additions to the prj.conf and reproduced the hang:

CONFIG_NO_OPTIMIZATIONS=y

CONFIG_FLASH_LOAD_OFFSET=0x27000

[Vidar Berg]

In the CC_PalWaitInterruptRND loop? Can you check what the boot validation type is set to in your bootloader?

[denis]

lbs-1.0.0.zipbootloader-neo.hex

sdk_nordic/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex

[denis]

Program boot loader:

nrfjprog -f NRF52 --recover

nrfjprog -f NRF52 --program

sdk_nordic/components/softdevice/s140/hex/s140_nrf52_7.2.0_softdevice.hex –-chiperase

nrfjprog -f NRF52 --program bin/bootloader-neo/bootloader-neo.hex

nrfjprog -f NRF52 --reset

Then use nrf connect on iOS to DFU the zip.

[Vidar Berg]

Thanks, I will try and see if I can reproduce it with your bootloader (hoping it will run on a DK).

nrfutil pkg display lbs-1.0.0.zip gives this:

DFU Package: <lbs-1.0.0.zip>:
|
|- Image count: 1
|
|- Image #0:
   |- Type: application
   |- Image file: zephyr.bin
   |- Init packet file: zephyr.dat
      |
      |- op_code: INIT
      |- signature_type: ECDSA_P256_SHA256
      |- signature (little-endian): b'f10f7aca6dc0353607a1fce8bbc46d53ee7d7092c07b86eeb87f0f7aa37c72a9c6514b3b3c6c58c33d968d8e0e1435530c64c83e7496fb51a5efc5c380ebc4a0'
      |
      |- fw_version: 0x00000003 (3)
      |- hw_version 0x00000034 (52)
      |- sd_req: 0x100
      |- type: APPLICATION
      |- sd_size: 0
      |- bl_size: 0
      |- app_size: 358152
      |
      |- hash_type: SHA256
      |- hash (little-endian): b'83d92fe619627e257d91ad857c124c5b671df6f6d450890795176f82a244daaf'
      |
      |- boot_validation_type: ['VALIDATE_GENERATED_CRC']
      |- boot_validation_signature (little-endian): [b'']
      |
      |- is_debug: False

So, the bootloader is not using the cc310 for boot validation, at least.