Now sure where exactly this belongs, but I already posted question abut the Musca S1 earlier, and this seems relevant. ARM support essentially seem to tell me that they cannot support GDB and they are not certain of DAPLink, and recommend ULINKPLUS debugger with ARM IDE. So wanted to get a sense from anyone who has attempted to use this.
In the following I describe the steps to obtain a base line, then provide description in what way GDB / DAPLink seems to misbehave.
To get a base line: ~~~~~~~~~~~~~ - I build 'samples/hello_world' app using Zephyr 'v3.4.0'. Copy the 'build/zephyr/zephyr.hex' file to '/media/user/MUSCA_S1' directory when the board is USB. Connect a terminal emulator to the UART exposed by USB DAPLink, e.g. 'picocom -b 115200 -y n /dev/ttyACM0'. I can see on the console the followinbg *** Booting Zephyr OS build zephyr-v3.4.0 *** Hello World! musca_s1 If I press the reset button, the app restarts as well. This is as expected. I note that this is entirely running as in secure mode, that it does not use TF-M.
- Next I start 'pyocd-gdbserver'. Then start a GDB session using the 'zephyr.elf' file, 'target remote localhost:3333' to connect it to the gdbserver. It connects ok. So I put a breakpoint at "main", do a 'monitor reset halt', and then continue. The breakpoint at 'main' is hit, I can obtain the backtrace to see it is correct as expected.
So my setup seems good.
Next I attempt to test a non-secure app with TF-M. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Build the app using Zephyr build env 'west build -b v2m_musca_s1_ns samples/tfm_integration/tfm_psa_test/ -DCONFIG_TFM_PSA_TEST_CRYPTO=y'. Copy 'build/zephyr/tfm_merged.hex' to '/media/user/MUSCA_S1'. Connect a terminal emulator, picocom, to the console, and hit the PBON (power on) button. I see the following output as expected on the console:
Musca-S1 Dual Firmware Version 1.9 [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! Booting TF-M 79a6115d3 [INF][Crypto] Initialising HW accelerator... complete. *** Booting Zephyr OS build zephyr-v3.4.0 *** ***** PSA Architecture Test Suite - Version 1.4 ***** Running.. Crypto Suite ****************************************** TEST: 201 | DESCRIPTION: Testing crypto key management APIs | UT: psa_crypto_init [Info] Executing tests from non-secure
This is as expected.
However, if I press the reset button the board does not appear to reset - this is unexpected. Has anyone seen a different behavior? Is the specific board that I have is misbehaving?
- Now I start PyOCD GDB server, start GDB and successfully connect it to the GDB server. The target is halted where it was executing, e.g. Remote debugging using localhost:3333 CC_HalWaitInterruptRND (data=data@entry=1024) at /home/zephyr/zephyrproject/modules/tee/tf-m/trusted-firmware-m/lib/ext/cryptocell-312-runtime/host/src/hal/cc3x/cc_hal.c:107 107 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR)); (gdb)
This is as expected.
- Next I put a breakpoint at 'sprt_main', then issue a 'monitor reset halt', then issue a 'continue',
The breakpoint is is NOT hit. I see a blue LED blink at perhaps 4 times per second.
This is unexpected. Has anyone seen this behave correctly? Do I have a board that is misbehaving?