SWV / Trace not working on MP1 in production mode

[SLasn.1]

Hi :) 

I have a custom-made board with the MP1 (stm32mp157D). The whole board is working fine, the A7 is running Linux and the M4 code runs fine.

But I cannot get SWV to work on the M4 chip.

I have reduced the code to an extremely simple code, nearly 100% generated by CubeIDE - I only added the following lines in the main to increment a counter called DDDEBUG and print using ITM_SendChar() :

/* USER CODE BEGIN 0 */
uint32_t DDDEBUG = 0;
/* USER CODE END 0 */

/**
 * @brief The application entry point.
 * @retval int
 */
int main(void)
{

  // ... (code generated by CubeIDE) ...


  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  DDDEBUG++;
  for (char* ptr = "test\n"; *ptr; ptr++)
    ITM_SendChar(*ptr);
  HAL_Delay(1000);
  }
  /* USER CODE END 3 */
}

The code compiles without errors, and it loads and executes fine, I can see in the debugger the counter incrementing (even in Live Expressions) and the ITM_SendChar function is called correctly.

I also double-checked the PCB design and I can confirm that the TRACESWO / SWO pin is connected correctly to the ST-Link (ST_Link V3 MNIE - an offical ST one, very small without a case). The SWDIO and SWCLK pins are connected and working otherwise the debugging would not work.

The problem is I get absolutely nothing in any of the SWV windows (SWV Data Trace, SWV ITM Data Console, etc.), neither "test" nor can I see the DDDEBUG variable changing. The config is attached and the recording is enabled. I tried both OpenOCD and GDB, they give exact same results (debugging works but not SWV).

Am I missing something here? Is it possible to use SWV at all with an MPU in production mode?

There is very little about SWV for STM32 MPUs, the only article I could find is this one on st wiki and a few topics here which are about engineering mode.

Thank you

Simon

[SLasn.1]

PS: I attached many screenshots of the configuration, including the ITM registers which look correct (but I'm no expert about these). See also the OpenOCD and GDB commands here:

C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_2.4.0.202409170845\tools\bin\openocd.exe "-f" "stm32mp157D_DK1_TEST_CM4.cfg" "-s" "C:/Users/Administrator/STM32CubeIDE/workspace_1.17.0/stm32mp157D_DK1_TEST/CM4" "-s" "C:/ST/STM32CubeIDE_1.17.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.0.202411041438/resources/openocd/st_scripts" "-s" "C:/ST/STM32CubeIDE_1.17.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.2.0.202409171044/resources/openocd/st_scripts" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444"

C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.2.0.202409170845\tools\bin\ST-LINK_gdbserver.exe -p 61234 -l 1 -d -z 61235 -s -cp C:\ST\STM32CubeIDE_1.17.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.2.0.202409170845\tools\bin -m 2 -g

I am using CubeIDE 1.17.0, and the firmware on the ST Link is updated to the newest available. The STM32MP1 firmware package is also the latest.

ITM SWT and CoreDebug Registers:

[SLasn.1]

Any thoughts anyone?

 

[SLasn.1]

Ok, here are my findings:

1. The Trace CLK needs to be enabled otherwise Cube gives a massive error while trying to set the ITM/DWT registers
   • check in Linux with:

     cat /sys/kernel/debug/clk/clk_summary | grep -E 'trace|enable|count|---

     (run "debug 1" first on my Linux to mount /sys/kernel/debug)
   • Enable it from the debugger by setting the "TRACECKEN" bit in RCC_DBGCFGR
   • Then check again in Linux, the "hardware enable" should have changed from N to Y
2. In CubeIDE, the "Core Clock" is NOT the M4 clock but the Trace clock (the one given by the command above), this needs to be set correctly (in my case 133.25 MHz)
3. Apparently this only works with OpenOCD and not with the ST-LINK GDB Server
   • This is particularly annoying because OpenOCD cannot reset the M4 (but GDB can) - and it takes about 5 minutes to stop the debugger and restart it... See https://community.st.com/t5/stm32-mpus-software-development/reset-stm32mp1-mcu-in-production-mode/td-p/602190