How to debug STM32MP1(Cortex-M4) firmware on user board?

[HAPPYDAY]

I have the STM32MP157C-DK2, and I plan to make a user board.

Before creating a user board, I have a question.

1. I want to know how to debug Cortex-M4 firmware on the user board. GDB debug is used in No. 7 in the link below.

https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP1_boards/STM32MP157x-DK2/Develop_on_Arm%C2%AE_Cortex%C2%AE-M4/Modify,_rebuild_and_reload_a_firmware

In STM32CubeIDE, STM32MP157C-DK2 can debug the firmware through ST-LINK MCU (OpenOCD), but there is no ST-LINK MCU on the user board, so I am curious about how to debug in STM32CubeIDE. Is debugging by connecting Segger J-link or ST-LINK (V2/V3) to the user board? I want to know if it is possible and how to do it if possible.

[Olivier GALLIEN]

Hi @HAPPYDAY​ ,

If there's no embed ST-Link in your design you can use external STLinkV2/V3 probe since you expose SWD signal on one connector.

Olivier

[HAPPYDAY]

Debugging works by connecting cables to CN7 and CN11 in STM32MP157C-DK2 and setting them as shown in the attached figure.

However, if you connect ST-LINK v2/v3 to CN12 pin header of STM32MP157C-DK2 and set it as shown in the attached picture, debugging will not proceed and a command aborted message will be displayed as shown in the attached picture.

Debugging does not work even if the resistors of SB17, SB19, SB20, SB22 are removed from the board and the debugging settings are changed. I don't know what the problem is. I want to know how I can debug using ST-LINK.

[gianlucarenzi]

Hello Olivier,

so, is it possible to use a STLink V2 (i.e. without Virtual COM Ports on connector) and without using the gdbserver on the STLink Embedded Hardware?

I am able to upload the firmware on the CoProcessor M4:

echo "firmwarename" > /sys/class/remoteproc/remoteproc0/firmware

run it using the following command:

echo "start" > /sys/class/remoteproc/remoteproc0/state

and it works, even compiled on debug mode, the trace is working fine:

cat /sys/kernel/debug/remoteproc/remoteproc0/trace0

Now I am trying to figure out how to debug it with a OpenOCD JTAG or STLink V2 debugger without using STM32CubeIDE.

Do I need to start gdbserver on the Linux core? How to find the ProcessID to attach? The PID is not shown as the code is running in a RPMSG based co-processor... Are there useful documentation on that instead of tell me: USE STLINKV3 AND STM32CUBEIDE sentence... ;)

Thank you,

Gianluca

[SLasn.1]

That would be SO great. I know this is more than a year later, but the problem is still there, the M4 core of the MP1 is such a nightmare to debug.

It took me 2 full days to finally get it working in CubeIDE (in production mode), and now that it's working I'm hit with the extreme slowness of Cube and its horrid GUI. So yes, debugging in VS Code = improve time efficiency by a factor 10.

There must be a way to debug from gdbserver directly - the way I understood is that Cube:

1. Connects to the A7/Linux via SSH
2. Uploads the ELF file
3. Start the M4
4. Launchs GDB (on the host machine - no on the A7 I am pretty sure) which connects to the STLink probe and attaches to the M4 core already running

Steps 1-3 we can do, that's easy (using the commands you showed above). Step 4 I hope we can see the command that Cube precisely uses and copy it. Once this is working, it's just about placing the whole GDB config into the Cortex-Debug VS Code extension.

@gianlucarenzi : just wondering, how do you get the /trace0 in the debug? And what trace are we speaking about, the SWO trace?

PS; Just a thought for ST: for all your MCUs, provide a simple launch.json for VS Code Cortex-debug extension, which works with the ST Link, which lets you debug in VS Code, and ideally also use basic SWO (at least the printf() functionality), that would be really golden.