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.
