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

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?

Parents
  • Thanks for the readregs tip.  I ran that quote a few times and the output is always the same:

    % nrfjprog --readregs
    R0: 0x00050B3C
    R1: 0x0008C8D0
    R2: 0x00000020
    R3: 0x3442AE31
    R4: 0x00000000
    R5: 0xEDB88320
    R6: 0x10001000
    R7: 0x00000000
    R8: 0x00000000
    R9: 0x00000000
    R10: 0x20030000
    R11: 0x00000000
    R12: 0x00000000
    SP: 0x2003FFCC
    LR: 0x000FB423 (nrf_dfu_validation_boot_validate)
    PC: 0x000F8A3A (crc32_compute)
    xPSR: 0x21000000
    MSP: 0x2003FFCC
    PSP: 0x00000000

    So it does seem to be stuck there.

    This is also what I see if I attach the VSCode debugger.

  • I forgot to add that nrfjprog --readregs will halt the CPU so execution won't continue after you have run this command. Does the PC value stay the same if you reset the board in-between each read?

    Edit: I don't see how the program could get stuck in the crc32_compute() function. Do you have logging over UART enabled in the NCS application?

Reply Children
No Data
Related