BUG - Using MCUBOOT breaks debugging

[KajbaM]

Describe the bug

Using MCUBOOT seems to break debugging. From my understanding there are two things that should be done, to avoid the issue:

• Disable flash breakpoints
• Load mcuboot build .elf file into debugger.

MCUBOOT fails to boot image, going into FIH_PANIC handler.

Firmware/Software Version

east 0.23.0

Hardware Version

Confirmed on multiple projects using nRF52840 (should be ARM core related)

To Reproduce

Have project with enabled mcuboot, use east util cortex-debug to generate launch.json file, try using debug function.

Additional context

The issue from my understanding is that debug function modifies flash memory of the device, because of that, mcuboot fails image confirmation and does not boot. There seems to be no way to completely disable all mcuboot checks. There seem to be two offending functionalities that can make this problem happen:

When debugger is launched without loading mcuboots zephyr.elf file, it seems that debugger does flash memory comparison upon launch. If that comparison fails, debugger proceeds to erase and reprogram flash memory. Of course, since debugger is unaware of mcuboot existance that leads to broken firmware being flashed on MCU. This does not seem to be the problem when using debuggers attach command.

Second offender is flash breakpoints functionality - flash breakpoints are intended to avoid limitation of number of breakpoints used to maximum number of hardware breakpoints. This limitation depends on actual MCU core being used. When debugger runs out of hardware breakpoints to use, it will start replacing instructions in flash memory with breakpoint instructions that will redirect instruction pointer to some common address that allows debugger to break execution of firmware. Because this means that contents of flash memory is no longer the same, MCUBOOT will again fail integrity check of firmware image. This breaks when using both debug and attach commands. With either attach or debug, reboot will fail on 7th-8th breakpoint being set - that is probably due to cortex m4 core having 8 comparators, 2 for literals 6 for instructions. Disabling all breakpoint and reseting the device does recover from this problem.

Workaround for this issue that worked for me was to add following to the lauch.json file under debug section:

      "loadFiles": [
        "/workspaces/project/app/ring/build/mcuboot/zephyr/zephyr.elf"
      ],
      "preLaunchCommands": ["monitor flash breakpoints = 0"]

This makes sure debugger loads mcuboot elf file and disables flash breakpoints functionality. With flash breakpoints functionality disabled, debugger will throw error when trying to set more breakpoints than hardware supports. Disabling some breakpoints/reducing number to what is supported does resolve issue without debugger re-attach needed.