Still fighting to setup SWO trace on STM32H7

[Gpeti]

Hello,

A few months ago I tried without success to setup ITM on a STM32H753I-EVAL2 board (and STM32CubeIDE). Now I'm trying again. There is a precise point I'm not sure about: the signal SWO is multiplexed on GPIO PB3, so I have to setup PB3 with alternate function SWO in my software. But is the SWO signal routed to the STLink ? Or in other terms: is it enough to plus the board through USB to the STLink to get the ITM outputs ?

Thank you

PS: I'm well aware of the following thread: https://community.st.com/s/feed/0D50X00009nNBBHSA4

[Pavel A.]

Sorry, forgot the most important setting :

In the SWV console window, click on the config icon and check ITM port 0 enable

Again, the debugger could do this automatically...

[Tesla DeLorean]

>>Again, the debugger could do this automatically...

Yes, it should. In most CM4 and CM7 implementations this is relatively straight forward. You can pull the prescaler/divider value from the ITM/DWT region.

The H7 is inherently a multi-core implementation, though the dual core has only recently been publicly disclosed. The plumbing and the management of multiple cores via the SWD is slowly maturing.

The code or debugging script made up for issues the debugger wasn't managing correctly.

Torsten Jaekel had done some more work on the debug units inside the parts based on non-public ARM documentation and experience with other SoC implementations. Some more detailed information is in the H7 RM and PM documents of more recent publication. Most of the work here came from 2017Q4 and 2018Q2/3, and when that came to a head with ST releasing a workable solution/method. Heaven only knows why this isn't worked into CubeIDE seamlessly in 2019Q3...

[Gpeti]

Thank you Pavel. i did exactly the same setup. But what debugger script / initialisation C code did you use ? Clive posted a C function but as far as I understood it must be called on debugger side ? Did you do the same or did you implement a function in your embedded software ?

[Gpeti]

Thank you Pavel, I did exactly the same setup. What is still not clear for me is the initialisation routine: Clive posted a detailed C function to be called by the debugger. But I'm calling this very same function from my C code. Is it correct ? How did you do on Atollic ? (debugger script or embedded function)

[Gpeti]

"The board with the V3 will likely not use 2 MHz SWD clock, but rather a 15 MHz one" I noticed that when GDB loads the software it displays "SWD freq: 24.000 KHz". It is consistent with the STLink v3 user manual.

So I guess I should modify the value when setting the divider ? But I cannot set 24MHz in Debug Configuration.

[Pavel A.]

Guillaume, there's nothing at all in my code to set up the debug interface. Both Atollic and Keil debuggers do it themselves.

Unless there's something hidden in the libraries.

-- pa

[Gpeti]

Really ? Then I really don't understand the code published in this post

So basically on keil and atollic, there is nothing else to do than setup the debug and launch the trace (and obviously instrument the code with ITM stimulus write). Probably due to this f... STM32CubeIDE.

[Tesla DeLorean]

Look, you're poking settings into the internal debug units attached to the core. The debugger software can do this auto-magically, you can use a debugger script, which sets values into the micro-controller, here for debug registers the driver doesn't set properly, but could equally set up clocks, pins and external memory interfaces, OR you can just run code on the micro-controller, from your application, that does the EXACT SAME combination of things.

IN JUNE 2018 the Keil debugger and ST-LINK drivers didn't configure the core correctly for SWV to work, this was therefore FACILITATED by code run on the core, EITHER as a Debug Script, OR arbitrary code run on the micro-controller directly. There isn't a lot of MAGIC with ARM cores, and the debugger typically accesses internal registers, peripherals and memory in the EXACT same fashion as code you write. So for example reading USART->RDR will clear the RXNE bit int USART->ISR, parking a debugger Peripheral View over the SDIO/SDMMC or USB FIFOs will break normal functionality.

If the registers are not set up correctly, no amount of hand waving from the side lines is going to produce usable data output from the device.

The registers involved don't have a lot of public facing documentation. ARM has manuals and app notes for DEBUGGER WRITERS, as it requires some technical competency in those areas, that most people seem to lack.

[Gpeti]

I fully understand that, but it's not the point. You have to see things from my perspective. ITM doesn't work, I see a post where you are discussing a debug script / code to be executed. I try it. Then another contributor says it doesn't need it. Doesn't it make sense I am surprised ? You have to admit this topic is not crystal clear (not your fault of course) 😉

Anyway thank you very much for your time and contribution, let's stop the discussion. I'm giving up ITM on STM32CubeIDE (anyway I will get rid of this ****** software as soon as my company agrees). Just entered a support request to ST, who knows.

[Pavel A.]

> IN JUNE 2018 the Keil debugger and ST-LINK drivers didn't configure the core correctly for SWV to work, this was therefore FACILITATED by code run on the core, EITHER as a Debug Script, OR arbitrary code run on the micro-controller directly.

This is strange... I've started with STM32F4 and Keil only in 2017, and don't remember enabling the ITM on the MCU side at all, and no using special scripts.

The oldest uVision I had was 5.24.

In the Silicon Labs IDE once there was a similar problem and they posted a similar code to enable ITM.

But before I had a chance to try it, they updated the IDE and now it also does this automagically.

Regards,

-- pa