Hi Arun,

In our daily development work, we use ULINK + ARM DS IDE to debug MUSCA S1. And the process is:

1. Add “b .” before SystemInit() in Reset_Handler() in startup_musca.c.
2. Connect debugger in ARM DS IDE.
3. Break the app with debugger. PC will stop at “b .” added in step 1.
4. Add breakpoints you need.
5. Manually set PC to “bl SystemInit” (next instruction of “b .”).
6. Continue to run and the breakpoints will be hit.
7. Press reset button on the board when necessary.
8. Re-connect to the debugger and repeat from step 3.

Officially TF-M does not support GDB neither PyOCD. If you have interests in supporting GDB in TF-M, your contribution is welcome. We are happy to review your patches. : )

Best regards,

Xinyu

From: Arun D via TF-M <tf-m@lists.trustedfirmware.org>
Date: Monday, October 23, 2023 at 03:51
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

Adding the the last part of my previous message:

When I issue GDB the 'continue' command, nothing is output on the console.


As an additional effort to work around the potential issue, I instrument 'runtime_init_c' (called by 'sprt_main') to have the code spin indefinitely waiting for a volatile unsigned int variable 'gdbSpinHere' varaiable to be changed from the default value of 0xffffffff to 0x0. Using a new debug session, when I issue GDB 'target remote localhost:3333', GDB connects to the PyOCD GDBServer. The backtrace shows 'runtime_init_c' is on the top of the stack. This is as expected.

Next I update 'gdbSpinHere' to set it to 0x0, then issue GDB with the 'next' command to step to the next line of code, and this seems to behave as expected.  So I put a break point at 'aes_crypt_cbc_wrap', which I expect to be hit, then issue 'continue'. The breakpoint is hit.

Now if I issue either step/next, the same breakpoint is hit. If I put a breakpoint at a function that should be hit, it is not. If I delete the breakpoints and issue 'continue', the same breakpoint is hit.

This is an unexpected behavior. Has anyone seen a correct behavior? Should this be any different if I use the ULINKPLUS probe?

Sine I have not used ULINKPLUS/ULINKPRO, is GDB server/GDB known to work? Does PyOCD work? If not is there an OpenOCD config file anyone can share?
--
TF-M mailing list -- tf-m@lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org