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.

[STOne-32]

Posted on June 19, 2018 at 19:53

 Dear Clive,  Rhodes,

To get Technical support on our products, Please go to our Online Support Service, you will have a dedicated Technical person to follow you carefully. 

I will be back for the questions below by the  end of the week. [ I'm travelling this week]

Regards,

STOne-32.

[STOne-32]

Posted on June 19, 2018 at 21:56

Dear Clive,

We understand your concern and IT IS our concern as well to provide real-time support on our public community. We are studying multiple strategies to fix that and I would love to hear your proposals as done in last Survey, We got your message! 

I highly encourage you to check our new On-Line support service, it is quite new and deployed on June 3rd.

Regarding the H7 MCU, we are preparing a major update soon and Yess, we have a new silicon revision as stated in our errata sheet and this is why I’m traveling:-) . We will be back by end of the week, stay tuned...

Cheers,

STOne-32

[Tesla DeLorean]

Posted on June 19, 2018 at 20:53

I don't subscribe to this multi-tier support methodology, and in all honesty have not found it to be productive in previous attempts.

The Maker, SW/HW Hacker, and social-media community here expect open and straight-forward communication, even if this contains bad news. Design cycles are shrinking, and users that are disaffected will likely take their designs elsewhere and you'll lose on multiple generations of design wins. You create conditions that marketing dollars later can't remediate.

Instead of pulling answers from an internal FAQ, perhaps the engineers cultivating that list can just participate here directly with answers.

I can only push so hard from the outside, change has to come from within.

[Torsten Jaekel]

Posted on June 19, 2018 at 23:43

Hi STOne-32,

thank you.

Sounds great and interesting. I am so keen on a new spin and new revision of the H7 MCU

(may I apply as prototype tester, honestly?)

Regarding commercial/professional online-support:

I cannot imagine that is your intention to deal with all hackers, small companies, students and individuals. We would overload your support team which should really work for (your) major and key customers.

My suggestion is just:

if something comes up here, or something comes up in your professional online support - please share info, keep us updated (update in both directions: from here to online support, from online support to here). I think, the online community is helpful for you, provides values - please give us back also helpful and valuable info/responses. Thank you.

You have mentioned interesting news, a 'new revision is coming' (what I understand). To be honest: still not any response if this SWO is a 'bug' (and it is it taken as known issue for potential new spins).

And how to figure out which revision of MCU we are using or we will use later? Is there CHIP_ID and REV_ID which can be read by FW/SW?

There is already something like 'Revision Y', in DBGMCU. ST-Link Utility shows this as 'Rev Y'. Which other revisions, e.g. ''Revision Z', are on the market? What are the differences ...?

Please, review also your datasheet and provide an updated datasheet on-time with new revisions, where the revision IDs can be clearly seen and distinguished (e.g. 'this bit broken in rev. X', 'this bit new/functioning with rev. Y at least'). And when talking about clocks, internal signal names - please make sure they are consistent with other names and info provided in datasheet, have an RDB tool to make sure the register offsets, base addresses ... are properly taken into datasheet. Thank you.

Thank you, STOne-32.

[Tesla DeLorean]

Posted on June 20, 2018 at 00:36

>>We would overload your support team which should really work for (your) major and key customers.

The forum does a good job of triaging this, but once the issues with everyone calling 'chip bugs' when their code doesn't work are filtered down to real issues that stand up to validation then some of the engineers with eyes on the gate level design need to step up.

The thing I have an issue with is questions going into a black hole, where there is clearly something amiss, and the general opaqueness.

[Torsten Jaekel]

Posted on June 20, 2018 at 04:52

Agreed: forum does a good job and before calling it a 'chip bug' - (I, me) make sure it is noy based on SW/FW bugs or misunderstandings. For my experience: if I try 'everything', I check datasheet, ARM TRMs, my code, and at the end it does not work still - something might be wrong in chip (or datasheet is not clear enough).

Gate level design? Do you mean gate level simulation? (silicon designers write code for high-level RTL (Verilog), not netlists and on gate level, except doing ECOs).

Gate level is useful to check timing, to look for glitches,  look for missing power clamps etc. SWO not working (always floating) might be a regular design verification (DV) test case, should be obvious w/o gate level simulation.

Anyway, a 'black hole' might be frustrating but I can imagine to deal with everybody, with beginners on SoC, starting FW developers ... is challenging. I do not want to argue or blame ST: chip design and testing is a tough job, bugs can happen and I have never seen a really 'error-free' chip tape-out. Just: if something seems to be strange - it would be great to verify again this special cases and to provide SW work-arounds or mark it as a 'HW bug'.

Let's see. I'll stay tuned how STM H7 will progress :)

[SofLit]

Posted on June 20, 2018 at 12:36

 ,

 ,

Dear Torsten,

 ,

As I noticed in your SW initialization the base addresses still ,incorrect , ,:

 ,

♯ define SWO_BASE , , , , , , , , , (0x5C00

03

00UL) ,

 ,

♯ define SWTF_BASE , , , , , , , , (0x5C00

04

00UL)

->,

♯ define SWO_BASE , , , , , , , , , (0x5C00

30

00UL) ,

 ,

♯ define SWTF_BASE , , , , , , , , (0x5C00

40

00UL)

 ,

Please re-check

PS: a new revision (Rev 4) of the reference manual is now available in ST web site. Debug infrastructure base addresses has been also corrected.

Best Regards,

STM32

[Tesla DeLorean]

Posted on June 20, 2018 at 14:48

>>Gate level design? Do you mean gate level simulation? 

I mean most of those things, basically someone who can go through the plumbing to understand what was built vs what was designed/intended. When I was doing this I was comfortable with everything from the design input to the polygon pushing, and when I got ICs back doing the parametric and characterization testing over process corners and temperature.

Would have thought the whole JTAG/SWD interface would have been a primary test conduit for the final test, boundary scan, and internal scan chains.

[Torsten Jaekel]

Posted on June 21, 2018 at 06:33

Upps, sorry, you are right:

I have fixed - no difference: SWO still floating, still not working.

BTW1:

I guess, the TPIU based address (in STM HAL FW used as 'TPI' ?) is also wrong:HAL drivers have: ♯ define TPI_BASE            (

0xE0040000UL

)                            /*!< TPI Base Address */

but I do not see anything on this address.

Even I changed to (for the MCU to access, where I think TPIU is visible)

♯ define TPI_BASE            (0x5C015000UL)

it fails still.

BTW2:

I have realized now also: if you play with these debug configs, CoreSight blocks in system - you can mess up your system!:

after flashing with such configuration done by MCU during run-time, the SystemWorkBench will complain with 'OpenOCD connection lost', 'cannot connect to target' or even stepping through the code is messed up (not working anymore, actually now nothing works anymore, even UART and RTOS is dead).

So, BE CAREFUL when MCU FW configures anything on debug infrastructure: when core is running and doing this config on power-up - you might lose debugger nconnection!

Biggest risk: once such wrong debug config code is in MCU FW and runtime code (executed now always on reset and power on) - you might never get access to MCU, e.g. in order to write a new flash image!

I give up on this SWO printf issue.

[Torsten Jaekel]

Posted on June 21, 2018 at 06:35

I agree: such a feature should be a test case (before tape-out. during DV and actually quite reusable due to similar CoreSight debug ARM IP used).

I give up, for me SWO printf (PB3) on STM32H7xx is broken.