Given the findings discussed in a previous thread, it seems that the existing Cortex-M7 cores from STM have a bug which triggers an unexpected breakpoint when a valid breakpoint occurs within a short time window after pending an interrupt.
When running in a debug session, such a rogue breakpoint halts the core in the debugger as usual, and execution can be manually resumed. However, when running as an unmanned standalone semihosted unit tests, execution halts and it is not possible to resume it; thus the test hangs. Attempts to find a workaround by masking interrupts via `cortex_m maskisr on` failed, since this interferes with the application interrupts. I suggest to address the issue by a patch in the OpenOCD source code, to automatically resume breakpoints at addresses that are not registered as a hardware (FPB) breakpoint (and eventually leave a line in the log). For cores that are not affected by this bug, this change should be harmless; for those affected, it would make the unmanned unit-tests pass and also reduce the annoyance during debug sessions. Liviu
