The Cortex M4 FPB unit will only support hardware breakpoints in the first 0.5GB of the address map (in the code region 0 – 0x1FFFFFFF). This means that flash (or software) breakpoints need to be used to set breakpoints in QSPI.
By default in e2 studio, it seems that the default breakpoint type is hardware (when debugging, right click in the addresses of the code, to see which type is the default, if the default is currently Hardware, it will show as “Switch Default e2studio Breakpoint type to Software”):-
If the default type of breakpoint is Hardware, then if a breakpoint is set in QSPI (outside the first 0.5GB of memory), then the GUI shows a breakpoint is set, but the Jlink does not actually try to set a flash breakpoint (as can be seen above a breakpoint is set at 0x600107FE in e2studio, but the JLink control panel does not have a breakpoint there).
If the default breakpoint type is set to software, then software (or flash) breakpoints can be set in QSPI flash (hardware breakpoints will still be used in the first 0.5GB. The FPB unit has 6 hardware breakpoints) :-
There is however currently a bug with JLink setting breakpoints in QSPI, sometimes, when a breakpoint is set at some addresses in QSPI, execution stops at the breakpoint. However, when execution is resumed, the default handler is hit. This may be caused by JLink failing to reprogram the QSPI with the code that was replaced for the software breakpoint, so when execution is resumed after the breakpoint in QSPI, JLink tries to re-program the QSPI with the original code, but fails to re-program the QSPI correctly, then the CPU fetches incorrect data from the QSPI flash, and causes the default handler to be called.
This does not always happen, sometimes breakpoints in QSPI work correctly. This behavior has been observed on S7-SK and S7-DK boards (these have different types of QSPI devices fitted). Other boards have not been tested.