EMT Tracing fails after clock configuration

[Derek3]

We are using an STM32F413 for development, as well as an I-jet Trace for debugging. Using CubeMX to setup the project for us as well.

Whenever the HAL library function "SystemClock_Config()" is called, we lose all tracing ability from the MCU. Everything up until that point will trace correctly. IAR also confirms that there is a clock signal (~12.5MHz) coming from the trace clock pin (due to the 25MHz HCLK).

Does anybody know why this is an issue? I don't see how configuring the clock would mess anything up, and the documentation surrounding ETM setup seems to be lacking for this chip.

[Tesla DeLorean]

Likely because the clock gearing is entirely wrong. The values coded for a 16 MHz HSI aren't going to mesh with those for HSE and/or PLL settings. The SWV has a divider against the core clock.

I suspect because the relevant ARM design/implementation documents are under NDA, and you make neither the chip nor the debugger. The CM4 side of the ETM is pretty generic, not ST specific.

The debugger scripts typically need to enable DBGMCU, TRACE and GPIO clocks, and initialize the GPIO pins in to AF0 mode. You could arguably script the DWT/SWD/ITM/ETM settings too, but the debuggers tend to have generic code for that and can pull specifics from the ROM Tables.

[Derek3]

I just tried switching the system clock to use HSI and the issue disappeared. Switching back to PLLCLK (which is is set up to use HSI as input) brings the issue again, so that definitely seems to be the problem.

I'm not entirely sure where to proceed from here. It is my understanding that the debugger should be able to sense the clock speed dynamically. I have looked at the limited documentation available and don't see any registers available to set clock-related info for the any of the ETM/DBG control registers.