Hey Raef,
Thanks for sharing your experience and observations!
You suggested a possibility that the secure / TF-M handler does not reset the non-secure side when there is a reset detected. That seems reasonable when PyOCD/GDB are used, i.e. when entirely with SW. Is there a TF-M configuration setting that needs to be enabled for this to happen? I am not sure if I remember this 100% for sure of reading this in some TF-M/Zephyr docs. Might anyone else have a suggestion? I will try your suggestion "reset configuration (musca_s1/target_cfg.c:212) seems to do the trick".
So this would mean that even with ARM's ULINK DS IDE, the same issue should be there. Would Xingyu Zhang be able to confirm this?
However, in my first message I mentioned that the pressing the reset button does not seem to reset the Musca S1. I would have expected this to issue a reset to both CPUs. This seems to be a HW issue.
About single stepping/breakpoint continue issues, I wonder if this has something to do with the ITM/ETM implementation.
Regards, -Arun.