Best practices for instrumentation logging with dual-core MCU

[Leon_MS]

Hi all,

  May I kindly ask some suggestions about the best practices, how to use e.g. printf for instrumenting logs that both of the dual M7 and M4 core could print at the same time?(Best case is through the same port...)

  Some background information: I was previously trying to write a debug library using ITM and SWV but seems not be able to work as expected. Details: https://community.st.com/t5/stm32-mcus-products/how-to-call-itm-sendchar-with-stm32h755-dual-core-mcu-but-on-cm4/td-p/604888

  Many thanks in advance!

[FBL]

Hello @Leon_MS 

 

I suggest the following example to get started with STM32Cube\Repository\STM32Cube_FW_H7_V1.11.1\Projects\STM32H745I-DISCO\Applications\ResourcesManager

You should enable multicore debugging in Project Options! 

[Leon_MS]

Thanks @FBL for your swift reply!

I just briefly went through the repository you mentioned. If I understood correctly. What I could do is by sharing e.g. UART1 from both M7 and M4 side, each core would print the logs independently?

But still I would like to ask(Just 100% make sure it's a dead-end approach): Sharing SWO by two cores, using ENSx bits from SWTF_CTRL register during run-time(e.g. changing ENSx bits within FreeRTOS tasks) would never let the TRACESWO pin prints out the characters(from two cores I mean...). Thanks!

[Tesla DeLorean]

Not entirely sure of the viability.

I'd probably lean to using two UART's. You could use one, but you'd likely need to manage the ownership / buffering so the granularity was a line of output that could ping-pong between cores so you didn't get intermixed jibberish.

Don't know how well SWV/SWO will share and the funnel mechanics in the dual-core H7. Strikes me a fraught with complications from the core to the pod to the debugger. If anyone's got a clear solution likely to be Segger or Keil.

[FBL]

 

Hello @Leon_MS 

1. Using Semaphore HSEM to synchronize access to shared resources will prevent both cores trying to access UART1 at the same time.

2. According AN5286, we need to configure the trace funnel and have trace clock enabled in DBGMCU_CR 

   to redirect the trace from M4 to SWO. 

In Section 63.5.7 from reference manual, the SWO trace funnel (SWTF) must be programmed to select which processor ITM will use it before trace is enabled. Port 0 is connected to the Cortex-M7 and Port 1 to the Cortex-M4. 

For more information about SWO you can refer to ARM CoreSight Components TRM.

[Leon_MS]

Thanks @Tesla DeLorean and @FBL for your kindly help! I think the first solution(HSEM Semaphore) "could be" a better option. Since I would like to use printing features purely provided by Nucleo board without any HW addon. -> To my understanding, USART3 is (the only interface) connected to ST-Link VCP port...

 

Also I am not willing to preset any hypothesis that the caller of printf, should only come from FreeRTOS tasks...(I am planning to use USB Device stack and LwIP stack in the same design. I am not studying them yet if they are implemented by FreeRTOS tasks.). So I would say so far this hardware-based semaphore implementation would be a very feasible option.

 

However.... I am still thinking about the contents shown from AN4989. I was checking the DBGMCU_CR bitmap from RM0399 Rev4, page 3365. There is no TRACE_IOEN and TRACE_MODE bits. Could be AN4989 only applied on single-core MCUs?

 

Thanks! 

[Leon_MS]

Sorry. I think the Chapter 9 of AN4989 was mentioning dual-core debugging should refer AN5286 and AN5361...

 

I also found another interesting thing. (Maybe it's caused by the messy codes I have edited.). When I was following those debugging instructions and start CM7 debug target, and then start CM4 debug target. There will be an error dialog shown from STM32CubeIDE something like "SWO has started on another core."

 

I am also wondering (let's forget CM7 now...) if there are any examples sent bytes from CM4 to SWO/SWV...

[FBL]

Sorry but I don't have an example. But as I mentioned you need to configure ENS1 bit in SWTF_CTRL and enable port 1 for CM4. It is possible that the issue you are facing in CubeIDE "SWO has started on another core" because SWO is still configured on CM7 but the message is from CM4.

[Leon_MS]

Thanks @FBL ! I will try later today for this solution.