No traceswo output on stm32H7xx

[Florian Otte]

Posted on March 16, 2018 at 07:40

Hi Forum. I am new to the H7 line of processors and the first thing I tried is getting printf() output on the traceswo pin of my nucleo-H743ZI. What I have tried:

1. The 'Everything out of the box' way:

Use cubeMX to configure sys to async trace, configure clocks, enable master clock out (to verify clock speed with a logic analyser).

Import the project to atollic truestudio and configure debugging to use the SWV, with the specific baudrate and core clock.

Write simples mainloop:

while(1) {

    ITM_Sendchar('T');

    delay(xxx);

}

Start a debugging session, configure trace port 0 and start tracing -> no output in atollic truestudio, no output on PB3 (verified with logic analyser)

2. The 'Do some manual work and hope the rest will resolve' way:

Same as above, with the exception of enabling the ITM unit manually:

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;

CoreDebug->DEMCR |= CoreDebug_DEMCR_VC_CORERESET_Msk;

ITM->LAR = 0xC5ACCE55; // Unlock Lock Access Registers

ITM->TCR |= ITM_TCR_DWTENA_Msk;ITM->TCR |= ITM_TCR_SYNCENA_Msk;ITM->TER |= 0x01; // Port 0ITM->TCR |= ITM_TCR_ITMENA_Msk;

Start debug session, enable tracing in atollic studio, THEN call my own init function - since the debugger overwrites the register values -> No traceswo output

3. The 'Do another variation of the non-working example' way:

Same as above, but I let the debugger handle the initialization and have the processor my init code before tracing is enabled through atollic stuido

-> Same result

4. The 'Try to do it by the book' way:

Here I really failed. What I tried:

Configure ITM manually, configure the SWO and SWTF unit manually.

Here my problem is that I do not know where SWO and SWTF are found in memory. The reference manual tells me that I can look up these adresses through the System ROM tables at adress 0xE00E0000.

However acessing these yields a fault -- Have not implemented the different faults, so i can not tell which is the one thats biting my ***! So I thought: Maybe I need to access these in priviledged mode.. same error.

(Atollic truestudio version - if that matters):

Atollic TrueSTUDIO� for STM32, Built on Eclipse Neon.1a.

Version: 9.0.0

Build id: 20180117-1023

Has someone a working example for trace output on the traceswo line on the nucleo-h743zi using atollic truestudio?

Any help or suggestions are apprechiated!

Florian

Addendum:

I received a response from Atollic.

XXXXX XXXXXXX

(Atollic Support)

Mar 16, 09:17 CET

Dear Florian,

There is a known problem with the STM32H7 which we have a ticket for at the moment. We hope to have this fixed until the next release. However, we haven't had a response from the correct ST department just yet if there's a problem with the MCU itself or if we've made a faulty configuration in the software somewhere. We're going to try to reach out again for a response.

Best regards

XXXXXX, Atollic Support Team#atollic-truestudio #itm-swo-trace #nucleo-h743zi

[Tesla DeLorean]

Posted on March 19, 2018 at 19:26

Sorry, I finally came back around to the H7 board. This doesn't seem to work in Keil either, so not exactly sure what it is using as a clock source, or if that impacts things or not. Didn't work even when clocking at 200 MHz.

Perhaps someone from ST can provide some insight?

DAHMEN.IMEN

‌

st.mcu

‌

30183

‌

[Florian Otte]

Posted on April 04, 2018 at 10:23

Update: Bump + Nothing resolved so far.

I read up a little bit on the cortex line of processors and I got this privileged mode stuff all wrong. I am developing bare metal so there is no need for a context switch on that side. Furthermore I tried to access System ROM tables at adress 0xE00E0000 - which is simply wrong. This adress is valid when trying to access the table through the debugger. But I tried to access them in Code, so the correct address would be 0x59000000 to 0x59000FFC... However accessing these yields a fault.

Still, after reading the reference manual again and again I could not find what i do wrong. Has someone else ever tried to access the System Rom Tables to get the base adresses for the SerialWireTraceFunnel or the SWO?

[Imen.D]

Posted on April 11, 2018 at 16:44

Hello

florian.otte

,

After check on your issue, I found thatmentioned

address

in the reference manual in 'System ROM table 1' and 'System ROM table 2' are not correct:

For the first table occupies a 4-Kbyte, 32-bit wide chunk of APB-D address space, from 0xE00E0000 to 0xE00E0FFC when accessed by the debugger, the correct address should be from0x5C000000 to 0x5C000FFC when accessed from the system bus.

Componentname

Componentbase address

(system bus)

System ROMtable 2 0x5C010000

SWO 0x5C003000

Timestampgenerator 0x5C005000

SWO funnel 0x5C004000

The second table occupies a 4-Kbyte, 32-bit wide chunk of APB-D address space, from0xE00F0000 to 0xE00F0FFC when accessed by the debugger, and from 0x5C010000 to 0x5C010FFCwhen accessed from the system bus.

Componentname Componentbase address

(system bus)

System CTI 0x5C011000

Trace funnel 0x5C013000

ETF 0x5C014000

TPIU 0x5C015000

=> T

he correct

address

will be added in the coming release of the STM32H7 reference manual.

Hope this helps you.

Best Regards,

Imen.

[Rhodes.Keith]

Posted on April 26, 2018 at 21:16

Hello Imen,

Can you explain what this means with regards to getting ITM_SendChar() working? Does this mean that TrueStudio must change their implementation? Is there something a user can do to get ITM_SendChar working?

Thanks...Keith

[Rhodes.Keith]

Posted on May 01, 2018 at 20:26

To any STM folk, is the new documentation coming soon? We are basing a new product design on the H743 MCU and I'm getting concerned that there has been no documentation update for something this serious (it is very serious to me) since October. Toolchain vendors (even Atollic, owned by you) will not fix this issue until you release the new documentation.

When can we expect an update?

Thanks...Keith

[Tesla DeLorean]

Posted on May 01, 2018 at 21:41

Would have thought the debugger could have found the ROMs from the debug-side interface. Not really feeling we're getting a complete explanation here, the errata is stale, and the whole thing smells like the H7 die is being respun to address some other issues, DSI not working properly being amongst the biggest.

ST honestly needs to be much more forthright and transparent, because this radio-silence approach is becoming awfully tiresome in 2018, where lead time push out 25-52 weeks and people have to make commitments to things they know are going to work properly, and be the same as the prototypes.

[Rhodes.Keith]

Posted on May 01, 2018 at 23:00

I agree with the transparency. These are big commitments we're getting ready to make. I've worked through all the problems with the STM32F427, but the H743 seems a bit more flaky and unsupported. It could be we're too early in this MCU's life cycle, but I hope not...

[Tesla DeLorean]

Posted on May 02, 2018 at 00:02

The part runs nicely, seems to be able to hit 500 MHz, so some head-room in the design. But 18 months in, the initial buzz is fading and ST perhaps needs to focus on not fumbling the ball.

The H7 Cube and EVAL/NUCLEO haven't had much attention, no info on a DISCO board. As you've noted the documentation is in need of a refresh.

As design cycles shrink, the roadmap, and product information need be more open.

[Tomas DRESLER]

Posted on May 18, 2018 at 18:34

I took an oscilloscope and Keil and saw the SWO (regardless of the setup of the prescaler) at frequencies around 4 MHz (when the prescaler was 9) or 0.1 MHz (when the prescaler was whatever, 399 or 3999). The core clock is reported at 400 MHz.

So I took the project and set core clock as 0.1 MHz in the ST-Link Trace dialog and voila, the printf over ITM started working!