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 */

}

[mƎALLEm]

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

[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 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.

[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

[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.

[mƎALLEm]

Posted on June 21, 2018 at 12:30

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

[Torsten Jaekel]

Posted on June 21, 2018 at 20:46

WHAUUA - GREAT - It works with this config!

Thank you.

[Amel NASRI]

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:

•  
•  
•  
• SWO related issue
• ==> Please refer to the document “
• https://community.st.com/0D50X00009nNBBHSA4
• �?. It is a step by step guideline on how to configure your project options with Keil µVision to be able to use ITM output with STLink.
• RM0433 errors and impacts
•  
• •  
  •  
  •  
  • Wrong registers base addresses
  • Discrepancies between registers offsets in detailed description and overview tables

==> 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.

•  
•  
• Discrepancies between Registers HAL names and RM ones

==> Some discrepancies are already addressed in previous Cube package version, others will come in the next version.

•  
•  
• Other topics:
•  
• •  
  •  
  • D2 SRAMs usage

==> It is recommended to enable the clock or the D2 SRAM before calling the main

•  
•  
• Bugs in RCC HAL driver impacting the usage of PLL2 as clock source for SDMMC

==> 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.

•  
•  
• What is the best way to use DMA and cache enabled?

==> 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.

•  
•  
• Check debug config with CubeMX

==> 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

[Tesla DeLorean]

Posted on June 21, 2018 at 18:35

Confirming here that SWV output working with NUCLEO-H743ZI

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

 

[Torsten Jaekel]

Posted on June 21, 2018 at 22:37

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
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

[David Viens]

Posted on June 23, 2018 at 22:44

That worked perfectly! Thanks. I guess the next HAL update will have this in the library?

Cheers

Links do not work:

<LINK NO LONGER ACTIVE>

<LINK NO LONGER ACTIVE>

[waclawek.jan]

DOC-2098-how-to-use-the-swo-on-stm32h7-devices