Ah apologies, I think I missed that you were having issues with the reset button. I've never seen an issue like that, the reset button seems to work at all time, so I think it might be an issue with your board. The only thing I can think of is that for some reason the reset button will sometimes cause the BL2 image loading to fail, and if you have the BL2 logging turned off there might not be any UART output between the reset and the BL2 failure, so it might look like a reset hadn't happened.
WRT what I was saying earlier, it's not that the non-secure side is being reset and the secure side isn't, it's about the permissions to write the reset register, and hence trigger the reset. So what's happening, I think, is that pyocd is attempting to write the reset register and that write is being ignored because it doesn't originate from secure state. pyocd _can_ issue secure reads and writes (because otherwise it wouldn't be able to read TF-M memory), so I think it should be possible to fix in pyocd.
Also, as you're debugging the CryptoCell driver, you might be interested to note that by default it is compiled in `relwithdebinfo` mode (to save space). You can set `-DMBEDCRYPTO_BUILD_TYPE=debug` to override this, which might aid your debugging experience.
Raef
________________________________________ From: Arun D via TF-M tf-m@lists.trustedfirmware.org Sent: 23 October 2023 11:22 To: 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