cancel
Showing results for 
Search instead for 
Did you mean: 

Check SWV ITM trace from code

ak52
Associate III

Hello,

I am using the STM32F767ZI MCU and was wondering if it is possible to check if a debugger is connected or not and if SWV is enabled, to avoid the UN-necessary looping when a printf is encountered.

These are my requirements:

  1. Check if the user has connected a debugger
  2. Check if the user has enabled ITM trace from the debugger and connected to the correct port.(Port 0 in this case)
  3. If both points 1 & 2 are not done, avoid the looping when a printf is encountered.

So when printf is called it invokes the _write function. Inside the write function we call ITM_SendChar(); in a loop. It is this loop which i want to avoid.

This is what i have so far:

 

static inline bool IsDebuggerAttached(void)
{
  return (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk);
}

static inline bool ITM_Port0_IsEnabled(void)
{
  return ((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0U) && ((ITM->TER & 1U) != 0U);
}

int _write(int file, char *ptr, int len)
{
  (void)file;
  int DataIdx;

  // Only send to ITM if debugger is connected AND ITM is active
  if (!IsDebuggerAttached() || !ITM_Port0_IsEnabled())
  {
    HAL_GPIO_WritePin(RED_LED_GPIO_Port, RED_LED_Pin, GPIO_PIN_SET); //just to test
    return len;
  }

    for (DataIdx = 0; DataIdx < len; DataIdx++)
    {
      //__io_putchar(*ptr++);
	ITM_SendChar(*ptr++);
    }

  return len;
}

 

IsDebuggerAttached works are i am able to recognize if the debugger is connected or not by checking the DHCSR register.

But i am not able to check if SWV is enabled and the correct port is connected.

To test this , i disabled the SWV from the debug configurations, but the LED did not light up, and when i placed a break-point on ITM_SendChar(), it hit that breakpoint.

ak52_0-1754461007018.png

Any help would be appreciated.

 

 

3 REPLIES 3
Andrew Neil
Super User

@ak52 wrote:

I am using the STM32F767ZI MCU and was wondering if it is possible to check if a debugger is connected


Yes: for Cortex-M3 and above you can check the DEBUGEN bit in DHCSR (the Debug Halting Control and Status Register):

https://community.st.com/t5/stm32-mcus-products/detect-debugger-connected-to-stm32l0/td-p/405688

 


@ak52 wrote:

and if SWV is enabled


Is it not sufficient just to know that a debugger is connected?

I've never tried it, but take a look at the Core Debug registers to see what you can glean...

https://developer.arm.com/documentation/ddi0489/f/debug/about-debug/debug-register-summary

 

PS:

Here's an ST Presentation on STM32H7 DBG:

https://www.st.com/content/ccc/resource/training/technical/product_training/group0/8a/bf/62/da/24/f0/49/7b/STM32H7-System-Debug_DBG/files/STM32H7-System-Debug_DBG.pdf/_jcr_content/translations/en.STM32H7-System-Debug_DBG.pdf

 

ARM Documentation for "Cortex-M7 Debug":

https://developer.arm.com/documentation/#q=debug&tab=all&cf-navigationhierarchiesproducts=IP%20Products,Processors,Cortex-M,Cortex-M7&numberOfResults=48 

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

@Andrew Neil wrote:


Is it not sufficient just to know that a debugger is connected?

I've never tried it, but take a look at the Core Debug registers to see what you can glean...

https://developer.arm.com/documentation/ddi0489/f/debug/about-debug/debug-register-summary


Checking DHCSR.DEBUGEN does confirm debugger presence, but in my use case, that alone isn’t enough.

The issue I’m tackling is that even with a debugger connected, ITM/SWV tracing might not be enabled or configured properly. In such cases, calls to ITM_SendChar() inside _write() will still run inside the for loop — wasting CPU cycles even though nothing gets output via SWV.

So I also tried checking:

  • ITM_TCR.ITMENA (ITM master enable),
  • and ITM_TER[0] (to check if stimulus port 0 is enabled).

However, these registers still report as enabled, even when the trace output isn’t showing up — i.e., the SWV output window in the debugger remains blank. So the condition passes, but no actual data is transmitted. That’s what led me to post this question in the first place.

So you'll need to have a trawl through the ARM documentation to see what other registers might be involved.

Maybe dump to a UART...

 

Maybe ask ARM - it's (probably) a core feature, rather than anything specific to ST...

https://community.arm.com/support-forums/f/architectures-and-processors-forum 

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.