SWV ITM Data Console is empty

[NateS]

This problem is common, but I've reviewed my setup and everything appears to be correct, yet it still doesn't work.

1. My programmer is an STLINK-V3PWR, connected via a 6 pin Tag-Connect (TVCC, SWDIO, NRST, SWCLK, GND, SWO) to an STM32F411CEU6.
2. In the STM32CubeIDE IOC, under SYS I've enabled Trace Asynchronous Sw.
3. In my STM32CubeIDE debug config, I'm using GDB, SWD, and enabled SWV at 25MHz, matching my SystemCoreClock. SWO clock is limited to 2000KHz (25MHz / 13 = 1920KHz).
4. In the SWV ITM Data Console settings, I've checked port 0. The red "Start trace" button is pressed.
5. My logging uses ITM_SendChar and ends with \n. I can suspend execution and step through the ITM_SendChar function in core_cm4.h: ITM and port 0 are enabled and ITM->PORT[0U].u8 = (uint8_t)ch; is executed.
6. Still, nothing appears in the SWV ITM Data Console or SWV Trace Log views.

At this point it seems like SWO is not connected, but it is definitely connected to pin PB3.

Next I tried this code:

while (1) {
	ITM_SendChar('h');
	ITM_SendChar('i');
	ITM_SendChar('\n');
	int i = 100000;
	while (i > 0) i--;
}

If I place this in main() after everything (in USER CODE BEGIN 2 where SystemCoreClock is 25000000) I still get nothing. However, if I place it before SystemClock_Config() (in USER CODE BEGIN Init just after HAL_Init() where SystemCoreClock is 16000000) then I see entries in the SWV Trace Log view: ITM port 16 and DATA_TRACE_VALUE (comp 0) (W).  I have no comparator configured. Maybe these are erroneous due to clocks not matching, but does it at least shows that SWO is indeed connected?

Edits:

I changed the SWV core clock to 16MHz and now I see entries in SWV ITM Data Console! But only when logging before SystemClock_Config(). Why doesn't it work after SYSCLK is changed to 25Mhz and I specify 25MHz for the SWV core clock? I also tried 96MHz, but got the same nothing.

SWV core clock 16Mhz with SYSCLK 25MHz and logging after SystemClock_Config(), I see gibberish SWV Trace Log entries. That makes sense. Changing the SWV core clock to 25MHz, I see nothing. That makes no sense! Maybe the STLINK-V3PWR doesn't work correctly? It's pretty new. I updated the firmware to the latest (V4.J3.B1.P4).

Changing SYSCLK to 16MHz (by using HSI), I do get logging. That's great, but I can't use HSI. I'm doing time sensitive operations (modulating a laser to keep it eye safe) and need to use HSE.

I don't know what else to try. I need logging and don't have a UART available because I was planning to use SWO. Any assistance is greatly appreciated!

[Tesla DeLorean]

I feel your pain, these fights can get annoying when they appear to defy logic. Using many STM32 families and boards I get into the habit of printing out the core details, chip revisions, and SYS, AHB, and APB clocks as the system perceives them. Output via USART one gets to confirm baud rates and HSE_SPEED, etc. Frequently I unpack the PLL settings, and plumbing down into the SDMMC peripherals, or whatever I'm using, as a sanity check.

Yes the SWO/SWV interface is extremely dependent of clocks being known, and correct. The pod side needs to be in agreement with the target. There's also a register on the target indicating the SWO's clock divider, with the H7's and others we were unpacking those too.

https://community.st.com/t5/stm32cubeide-mcus/still-fighting-to-setup-swo-trace-on-stm32h7/td-p/273722

Couple of forum transitions have left this one mutated..

https://community.st.com/t5/stm32-mcus-products/stm32h7-swo-printf-not-working/m-p/389357

  //SWO current output divisor register
  //This divisor value (0x000000C7) corresponds to 400Mhz
  //To change it, you can use the following rule
  // value = (CPU Freq/sw speed )-1

   *(__IO uint32_t*)(0x5C003010) = (*(__IO uint32_t*)(0x5C003010) & 0xfffff000) | 0x000000C7; 

This presumed the 2 MHz connection via SWCLK of the ST-LINK/V2, would be much higher on V3 probably 12 or 15 MHz. The register bank may need to be unlocked, and different on other cores. But the low order 12-bits were a baud rate divider / N-1 count

[NateS]

Doesn't the IDE or programmer do all the SWO clock, divisor, etc setup?

I get logging via SWO now, but I find after about 85 log messages, the logging stops. **bleep**, it's always something. Maybe I'm writing too fast, but I need to log at that speed. It's not even super fast. In the past it was fine via UART. My code keeps running and my device works, but the logging stops.

Are there buffer or other settings for SWO? I've tried slower (1000kHz) and faster (6000kHz) SWO frequencies.

[Tesla DeLorean]

Core side it's just a shift register with no buffer depth, pretty simple UART implementation, bit like the ARM7/9 DCC

On the pod it needs to be buffered and managed so it's not lost as the SWDIO/SWCLK traffic transits. I don't think ST provides much implementation detail on how it works or if buffers can be expanded or configured.

Yes, in an ideal situation the "debugger" should manage the experience, but it doesn't know what the core and clock is doing, and doesn't try to unpack that, or the source clocks on the STM32 side, which are board/implementation dependent. Which is why there needs to be convergence between the speed you say the core is running, and the speed it actually is running.

[NateS]

I do configure SWV in CubeIDE by telling it the core clock. It must choose a divider from that to get the SWO frequency. I assume that has to be communicated somehow with the STM32 so it uses the right SWO frequency.

At any rate, it does work with just the CubeIDE config and calling ITM_SendChar. By "work" I mean I get logging until about 85 messages. If I send messages in shorter bursts, I can get more, presumably without limit. It seems that as soon as I send too much too fast, logging is gone. It's really bad usability.

I will try a V3SET, V3MINIE, and a J-Link Mini (on order) to see if those behave differently.

[NateS]

I tried with a V3SET and V3MINIE: both of them log over SWO without randomly failing when many messages are sent rapidly. It's the same code, the same USB port, everything is the same as with the V3PWR, except the V3PWR stops logging after ~85 messages when messages are sent at about 60Hz. My conclusion is that the V3PWR is unreliable junk. :(