STM32H7 SWO printf not working

[Torsten Jaekel]

Posted on June 06, 2018 at 08:02

I try also to use SWO printf (SWV, SWO viewer in ST-Link-Utility). It is not working.

I am aware of this thread:

https://community.st.com/s/question/0D50X00009XkWZQSA3/no-traceswo-output-on-stm32h7xx

But I tried step-by-step to use (configure, enable) the Debug infrastructure in the STM32H7 chip (e.g. configure Debug, ITM, force SWO signal to work ...). Nothing works.

(it looks to me based on datasheet - you had to get familiar with something else, e.g. DBGMCU (which is not an ARM IP block, ARM TRM)

I see in debugger, that the

ITM_SendChar puts my characters into ITM FIFO (it looks as ITM enabled, FIFO is free).

But nothing comes out (PB3 is floating).

What I have realized:

a) the

PB3 (SWO) signal is floating, not driven (it works as GPIO, but not as Debug SWO signal, also pull-up is OK, BTW: there is a lot of noise on this signal!)

b) the datasheet, manual

<LINK NO LONGER ACTIVE>

has a lot of of

discrepancies (and incorrect information, e.g. register offsets in detailed descriptions are not matching with the overview table, reset defaults are different, some reserved bits are set when registers are read in debugger ..., e.g. DBGMCU_IDC).

How to use ITM (SWO, SWV)?

Why this SWO signal is not driven (it is floating)?

(this MCU is so 'strange', I am quite frustrated to bring up a project ... is this MCU not so mature or not well tested (the DV did not cover all features ...? Do we have to wait for a next spin and tape out ...?).

Please, if you have any idea ... I appreciate.

What is your experience with this MCU? (and correctness of datasheet? Reasonable to use this revision of MCU already?)

My issues so far:

0. Datasheet and HAL (H-Files) use different names, or HAL misses still something (e.g. where is SWO, SWTF).

I guess, I had to configure something on SWTF - but what, how to find in HAL and are all the blocks, register offset,

base addresses defined in HAL defined or given in datasheet correct?

1. SDMMC1 PCLK cannot be taken from PLL2

2. D2 SRAMs are powered off - not usable as 'regular' memory (if loaded by debugger during reset or accessed w/o to

enable SRAM clock before)

BTW: if you access such not enabled or existing memories - the bus fabric does not generate a Bus Fault,

instead the entire system will hang, potentially the bus fabric will hang forever - do not access 'memory holes'.

3. Using DMA and caches enabled - it seems to be mandatory to initialize also MPU

(cache maintenance could fail, otherwise).

4. SWO (SWV, printf via ITM) is completely broken (or ST-Link-Utility does not configure this CM7 properly)

5. Datasheet has a lot of wrong information (e.g. wrong debug block/ROM table register based addresses,

register offsets, but HAL H-files seem to be a bit more correct - hard to trust).

6. (not a bug, but a tough way to figure out:( SDMMC1 can only access AXI SRAM (D1 SRAM, no other SRAMs).

(if you let try to use other memories by SDMMC1 - the same as 2.: the system hangs,

the SDMMC1 (DMA) hangs forever - no bus fault exception ...!

If have realized: if you let DMAs access not available memories - no errors/exceptions, just the DMA

engine/peripheral is dead forever - be careful, also when caches are enabled and DMA descriptors are not

'coherent')

This is a nice MCU (keen on the performance promises and some nice HW features, e.g. the fractional PLLs!, the delay buffers - it would be nice to have it available also on the SPI MISO signals ...) but it is so hard to bring up a similar (existing) project on this MCU.

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Torsten Jaekel]

Posted on June 13, 2018 at 08:30

Update:

debug session done:

I do

NOT

see SWO, SWTF etc. in debugger (via ST-Link Utility and memory display).

I see:

4x Generic IP (assuming: ITM, DWT, FPB, SCS), 2x CoreSight IPs (CTI, ETM) and 2x ROM tables (ROM1 and ROM2).But nothing points properly to SWO, SWTF blocks.

Instead, I guess, the entries in Debug ROM2 are wrong (if I decode and use the entry values - they seem to lead to not-existing blocks and does not seem to match with datasheet).

The SWO as debug access 0xE00E2000, SWO funnel (assuming it should be SWTF (a consistent wording/abbreviation would be nice 😉  ) as 0x0E00E4000, Trace Funnel 0xE00F3000 are

NOT

visible via debugger.

The SWO pin PB3 is still floating (assuming the debug block in D3 is broken or does not have a clock).

BTW:

- CubeMX for H7 is buggy: the debug config, e.g. asynchronous trace vs. synchronous trace, generates errors (which are not reasonable for me, it complains about pin conflicts which are not really correct: asynchronous trace, which should be SWO ITM output seems to assume a 4bit Synchronous Trace config, with a TRACECLK input pin still available, anyway - it does not generate any related code for this debug config, just a (broken) cross-check)

- the datasheet for STM32H7, esp. the debug infrastructure, has a lot of incorrect information (doubled register offsets, wrong default reset values, discrepancies between text/details and summary tables etc.)

- it talks about '

two cores'

(a copy and paste mistake?)

I assume also, some CoreSight ARM IP cores used in the chip have a different ARM revision number, e.g. r0p0 vs. r0p1 (assuming it at least one block is an r0p4) or even a CoreSight V2.0 or SOC-400 (actually 'too new' for this chip). Very confusing: the datasheet does not match with what can be seen via debugger (decoding an DEVID value confuses me and does not match with datasheet).

I cannot find the SWO and SWTF blocks

: not via debugger (no SWO block in region 0xE0000000..0xE00FFFFF), not from MCU view (0x59xxxxxx, 5Cxxxxxx ... - what is the correct address????).

BTW: it looks to me, that the integrated ARM IP cores (CoreSight) have still the Integration (and Test) Features enabled (for testing before tape-out, at least the Integration Enable bit can written, but the LAR registers fail to write on several blocks).

I am lost (assuming a serious bug in debug infrastructure, missing clocks inside chip (CK_DBG_D3) or IP blocks not properly configured for tape-out).

[Torsten Jaekel]

Posted on June 14, 2018 at 01:37

Update:

I can see via ST-Link Debugger these blocks:

0x5C000000 : Sys ROM 1

0x5C010000 : Sys ROM 2

0x5C001000 : DBGMCU (not an ARM CoreSight component)

0x

5

C

00

3

000 : SWO (address given wrong in datasheet)

0x

5

C

004000 : SWTF (SWO and SWTF not defined in H files)

0x

5

C

005000 : TSG

0x5

C

011000 : CTI (System)

0x5

C

013000 : Trace Funnel

0x5

C

014000 : ETF (not via 0xE00xxxxx)

0x5

C

015000 : TPIU (not via 0xE00xxxxx)

0xE0000000 : ITM

0xE0001000 : DWT

0xE0002000 : FPB

0xE000E000 : SCS

0xE0041000 : ETM

0xE004

3

000 : CTI (CM7)  (address given wrong in datasheet figures)

Remarks:

Some addresses given in datasheet are not correct, e.g.

0x5

9

00xxxx is not access-able (see the correct addresses above,

9 --> C

).

The TSG (Time Stamp Generator) works pretty nice: it gives you a 64bit time stamp value, running with HCLK - easy to use if a time base is needed, e.g. to measure execution clock cycles (just enable it and set frequency base).

Still no success to see SWO coming out, even trying this config via MCU:

void ITM_enable(void)

{#define SWO_BASE          (0x5C000300UL) //not defined in stm32h743xx.h#define SWTF_BASE         (0x5C000400UL)    uint32_t SWOSpeed = 2000000;/* we have default 2 Mbps SWO speed in ST-Link SWV viewer */    uint32_t SWOPrescaler = (SystemCoreClock / SWOSpeed) - 1; /* SWOSpeed in Hz */    /*     * ???? executed but still not yet SWO output generated     */    *((uint32_t *)(SWO_BASE + 0xFB0)) = 0xC5ACCE55;  //write LAR    *((uint32_t *)(SWO_BASE + 0x0F0)) = 0x00000002;  //protocol mode, 1 or 2    *((uint32_t *)(SWO_BASE + 0x010)) = SWOPrescaler;    *((uint32_t *)(SWTF_BASE + 0xFB0)) = 0xC5ACCE55; //write LAR    *((uint32_t *)(SWTF_BASE + 0x000)) = 0x00000301;    CoreDebug->DEMCR = CoreDebug_DEMCR_TRCENA_Msk; /* enable trace in core debug */    DBGMCU->CR = 0x007001B7;       /* enable DBG */    ITM->LAR = 0xC5ACCE55;         /* enable access to ITM, write LAR */    TPI->SPPR = 0x00000002;        /* 'Selected PIN Protocol Register': Select which protocol to use for trace output (2: SWO UART NRZ, 1: SWO Manchester encoding) */    TPI->ACPR = SWOPrescaler;      /* 'Async Clock Prescaler Register'. Scale the baud rate of the asynchronous output */    ITM->TCR = /*ITM_TCR_TraceBusID_Msk | */ ITM_TCR_SWOENA_Msk | /* ITM_TCR_SYNCENA_Msk |*/ ITM_TCR_ITMENA_Msk; /* ITM Trace Control Register */    ITM->TPR = ITM_TPR_PRIVMASK_Msk;      /* ITM Trace Privilege Register */    ITM->TER = 0x1;                /* ITM Trace Enable Register. Enabled tracing on stimulus ports. One bit per stimulus port. */    DWT->LAR = 0xC5ACCE55;         /* write LAR */    DWT->CTRL = 0x000003FE;        /* DWT_CTRL */    TPI->FFCR = 0x00000100;        /* Formatter and Flush Control Register - should be RO */}

[Torsten Jaekel]

Posted on June 14, 2018 at 06:34

Update:

I guess the DBGMCU registers (0x5C001000) seem to be completely messed up (and not working).

a) This DBGMCU register block in STM32H7xx is completely different (and new) compared to other MCUs, e.g.

     there is

not

a TRACE_IOEN and TRACE_MODE register field in DBGMCU_CR (offset 0x04).

b) instead: you

can write ALL registers even marked as 'reserved'

(see DBGMCU in

    datasheet):

   

ALL registers

in offset range 0x04..0x58 (except 0x10..0x18) are

fully 32bit write-able

(all mentioned registers,

    even marked as 'reserved') - I cannot imagine that is correct

    (why having so many unused, fully write-able registers?)

So, I assume, these DBGMCU registers in STM32H7xx MCU are

just a RAM

, no functions behind all the bits (nothing happens if you write all DBGMCU registers with value 0xFFFFFFFF, 0x00000000 etc.).

It is maybe left as a simulation/test RAM, instead to associate really with debug enable and config features (registers and their bits not really wired inside RTL).

The only good news   😉   :

if

you need RAM (registers) which are fully 32bit write-able and they should survive a System Reset

- use the DBGMCU registers (ALL, including all 'reserved'.   🙂   ). Yes, they are not reset and cleared by a hard system reset(this is correct). But I guess it was not the intention to have a surviving RAM: it looks more as: this DBGMCU block is not a real one, still a RAM simulation for testing.

I am lost and give up. I am quite sure that the debug infrastructure in STM32H7xx chip is not really correct and might have still some 'integration' and test features in RTL enabled instead of a real functionality.

The

P

B3

pin

cannot

be enabled as an actively driven SWO signal. It is still floating (potentially due to a broken DBGMCU block, e.g. the debug clock config does not work - BTW: where is CK_DBG_D3 and CK_DBG_D1 configured/enabled?).

==>

It would be really appreciated if ST Micro could check, provide more info, release an app note or other hints how to use the SWO and DBGMCU registers.   :o   Thank you.

Just:

If I use ST-Link as debugger for memory dumps and I read too many registers (from DBGMCU start 0x5C001000) - the MCU seems to stop and hang. So, the debugger seems to hit a 'memory hole' which seems to result in a locked up bus fabric (for the MCU, not for the debugger).Read just 0x100 bytes for a memory dump of DBGMCU (0x5C001000): otherwise MCU will stall, even debugger (ST-Link) is still alive and working.

[David Viens]

Posted on June 16, 2018 at 17:29

Hi.

Got the same issue of SWO not outputting anything (checked on scope) on a STM32H743ZIT6 (REV Y).

Porting from a STM32F745 project on the same PCB rev where SWO was working fine.

Without SWO might as well just program blindly. This is very disappointing, especially since ST doesn't even answer or acknowledge the issue in the two threads.

Regards

[Tesla DeLorean]

Posted on June 18, 2018 at 15:43

Yeah, bit frustrated with the response here too. Not seen SWV connectivity work on any H7 board (have EVAL and DISCO here), and fiddled with it a lot, although

Jaekel.Torsten

‌ hasdone some heavier lifting on the interface/scope side.

Other threads for completeness

https://community.st.com/0D50X00009XkWZQSA3

https://community.st.com/0D50X00009XkaaeSAB

[Tesla DeLorean]

Posted on June 18, 2018 at 17:01

Complaints about this spanning over 6-months, not addressed in errata

<LINK NO LONGER ACTIVE>

benahmed.mohamed

‌ please can we get an official position from ST for this, and what's happening with the H7 product line.

[Rhodes.Keith]

Posted on June 19, 2018 at 16:58

I totally agree. This lack of attention is troubling. We have a go/nogo decision on this part that is looming. I am very nervous about the mystifying lack of information flow from ST.

benahmed.mohamed

PLEASE provide info.

[Tesla DeLorean]

Posted on June 19, 2018 at 17:59

Please up-vote the topic by checking 'I have this problem too'

Kling.Brian

‌ please have someone responsible the MCU and H7 lines, and marketing, tackle some of these issues, it is counter productive to let them fester. If there is a problem with the current silicon please identify/acknowledge that. If there is a new step of the silicon, please also establish that and provide information about availability moving forward.

[Torsten Jaekel]

Posted on June 19, 2018 at 19:06

Yes, I am thinking in a similar way: this STM32H7 is not  yet 'mature' enough for real products.

In addition to this issue I have some other issues (e.g. PLL2 for SDMMC, USB not working if you forget to enable a power monitor, SDMMC can hang on commands if something goes wrong (to fast clocks, long wires), DMA on memory holes do not give any error/fault handler, just hang forever ...).

I intend to stop using this MCU (maybe to give it a new trial after a new silicon spin and revision).

This MCU is 'too  sensitive'. It consumes meanwhile too much effort and time to bring it up, to debug issues, to study datasheet again and again and to cope with so many missing info and discrepancies in datasheet.

Meanwhile I have started also to digest ARM TRMs, just to understand better how some blocks (as ARM IPs used in silicon) should work. The 'problem': hard to figure out which versions (e.g. r0p1) of ARM SoC IPs are used.

BTW:

There is another brand (company) with a CM7 and even 600 MHz (instead of 400 MHz).   😉