2018-06-05 11:02 PM
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.
Solved! Go to Solution.
2018-06-21 03:30 AM
Dear all,
For SWO printf (SWO viewer in ST-Link-Utility) could you please use the following intialization:
*(__IO uint32_t*)(0x5C001004) = 0x00700000;
//UNLOCK FUNNEL
*(__IO uint32_t*)(0x5C004FB0) = 0xC5ACCE55;
*(__IO uint32_t*)(0x5C003FB0) = 0xC5ACCE55;
//SWO current output divisor register
//This divisor value (0x000000C7) corresponds to 400Mhz
//To change it, you can use the following rule
// value = (CPU Freq/sw speed )-1
*(__IO uint32_t*)(0x5C003010) = (*(__IO uint32_t*)(0x5C003010) & 0xfffff000) | 0x000000C7;
//SWO selected pin protocol register
*(__IO uint32_t*)(0x5C0030F0) = 0x00000002;
//Enable ITM input of SWO trace funnel
*(__IO uint32_t*)(0x5C004000) = *(__IO uint32_t*)(0x5C004000) | 0x00000001;
//RCC_AHB4ENR enable GPIOB clock
*(__IO uint32_t*)(0x580244E0) = *(__IO uint32_t*)(0x580244E0) | 0x00000002;
// Configure GPIOB pin 3 as AF
*(__IO uint32_t*)(0x58020400) = (*(__IO uint32_t*)(0x58020400) & 0xffffff3f) | 0x00000080;
// Configure GPIOB pin 3 Speed
*(__IO uint32_t*)(0x58020408) = *(__IO uint32_t*)(0x58020408) | 0x00000080;
// Force AF0 for GPIOB pin 3
*(__IO uint32_t*)(0x58020420) = *(__IO uint32_t*)(0x58020420) & 0xFFFF0FFF;
Don't forget to set the right system clock frequency in ST-Link Utility/SW Viewer.
Best Regards,
STM32
2018-06-21 08:42 AM
Posted on June 21, 2018 at 17:42
Hi All,
I try to summarize almost all discussed topics & issues in this post, with an answerfor each item:
==> Almost all errors and discrepancies are addressed in
<LINK NO LONGER ACTIVE>
that is already on the web. If you still note other errors, you may highlight them for us.
==> Some discrepancies are already addressed in previous Cube package version, others will come in the next version.
==> It is recommended to enable the clock or the D2 SRAM before calling the main
==> This is a known limitation in RCC driver that was confirmed in the thread “
<LINK NO LONGER ACTIVE>
�?, where a patch is already provided. The official fix will be available in the next version of STM32CubeH7 package.
==> Please refer to the application note
<LINK NO LONGER ACTIVE>
(Level 1 cache on STM32F7 Series and STM32H7 Series) which provides examples of cache configuration on M7 based devices.
==> Is it possible to describe the problems you are facing with CubeMX in a separate discussion? This will be easier to handle by our STM32CubeMX experts?
If you consider that there are other open points not mentioned here, please highlight them in new posts. Ideally, you can detail them in separate threads so that they don’t get lost in long discussions.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2018-06-21 11:35 AM
Confirming here that SWV output working with NUCLEO-H743ZI
https://community.st.com/0D50X00009nNBBHSA4
2018-06-21 01:37 PM
For all others convenience - the code 'translated' to understand what is done.
It works nos - thank you again.void ITM_enable(void)
{
#define SWO_BASE (0x5C003000UL)
#define SWTF_BASE (0x5C004000UL)
__IO GPIO_TypeDef *GPIOBRegs = (GPIO_TypeDef *)GPIOB;
uint32_t SWOSpeed = 2000000; /* [Hz] we have 2 Mbps SWO speed in ST-Link SWV viewer
if we select 400000000 Hz core clock */
uint32_t SWOPrescaler = (SystemCoreClock / SWOSpeed) - 1; /* divider value */
//enable debug clocks
DBGMCU->CR = 0x00700000; //enable debug clocks
//UNLOCK FUNNEL
//SWTF->LAR unlock
*((__IO uint32_t *)(SWTF_BASE + 0xFB0)) = 0xC5ACCE55; //unlock SWTF
//SWO->LAR unlock
*((uint32_t *)(SWO_BASE + 0xFB0)) = 0xC5ACCE55; //unlock SWO
//SWO divider setting
//This divider value (0x000000C7) corresponds to 400Mhz core clock
//SWO->CODR = PRESCALER[12:0]
*((__IO uint32_t *)(SWO_BASE + 0x010)) = SWOPrescaler; //clock divider
//SWO set the protocol
//SWO->SPPR = PPROT[1:0] = NRZ
*((__IO uint32_t *)(SWO_BASE + 0x0F0)) = 0x00000002; //set to NRZ
//Enable ITM input of SWO trace funnel, slave 0
//SWTF->CTRL bit 0 ENSO = Enable
*((__IO uint32_t *)(SWTF_BASE + 0x000)) |= 0x00000001; //enable
//RCC_AHB4ENR enable GPIOB clock - maybe done already
RCC->AHB4ENR |= RCC_AHB4ENR_GPIOBEN;
//Configure GPIOB_MODER pin 3 as AF
GPIOBRegs->MODER &= ~GPIO_MODER_MODER3; //clear MODER3 bits
GPIOBRegs->MODER |=
GPIO_MODE_AF_PP << GPIO_OSPEEDER_OSPEEDR3_Pos; //set MODER3 PIN3 bits as AF
//Configure GPIOB_OSPEEDR pin 3 Speed
GPIOBRegs->OSPEEDR &=
~GPIO_OSPEEDER_OSPEEDR3; //clear OSPEEDR3 bits
GPIOBRegs->OSPEEDR |=
GPIO_SPEED_FREQ_HIGH << GPIO_OSPEEDER_OSPEEDR3_Pos; //set OSPEEDR3 PIN3 bits as High Speed
//Force AF0 for GPIOB_AFRL, AFR[0] for pin 3
GPIOBRegs->AFR[0] &= ~GPIO_AFRL_AFRL3; //clear AFR2 PIN3 = 0 for AF0
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?
2018-06-21 01:46 PM
WHAUUA - GREAT - It works with this config!
Thank you.
2018-06-23 03:44 PM
That worked perfectly! Thanks. I guess the next HAL update will have this in the library?
Cheers
2018-07-07 05:41 AM
Nice!!
2018-08-13 01:10 AM
Links do not work:
<LINK NO LONGER ACTIVE>
<LINK NO LONGER ACTIVE>
2018-08-23 04:29 AM
2018-08-23 04:30 AM