for the reset issue we discussed with PyOCD maintainers and I believe there will be shortly a fix for that in PyOCD itself that will be integrated in an upcoming new release (i.e. PyOCD issuing secure writes to reset)
for the breakpoints issue, we have been pointed to this patch: Add mps2 an521, reset on loading to Ram and soft-bkpt-as-hard (#1638) · pyocd/pyOCD@6dc261a (github.com) . In particular, soft-bkpt-as-hard will force breakpoints to always be HW breakpoints; hopefully this would remove any inconsistent behaviour that might be due to SW breakpoints.

Thanks, Antonio

Add mps2 an521, reset on loading to Ram and soft-bkpt-as-hard (#1638) · pyocd/pyOCD@6dc261a

* Add support for mps2_an521 * Generate reset when loading to Ram * Add support for soft-bkpt-as-hard

github.com

From: Arun D via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, October 23, 2023 11:22
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: Various issues in successfully using GDB to debug secure apps on Musca S1 connected over USB DAPLink to a Linux host

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.
--
TF-M mailing list -- tf-m@lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org