As long as this is limited to cores that are known to maybe have such a bug, it doesn't affect me. In general I don't think OpenOCD can always know whether a halt is caused by a bug or not. Cross triggering is a good example of that, but even delayed memory access breakpoints are hard to match up, unless the hardware explicitly tells you the reason.
Tim On Sat, Jul 22, 2023 at 12:07 AM Liviu Ionescu <i...@livius.net> wrote: > 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 > > > > > > > > > >
