STM32 Dual Core using peripherals (UART) with both cores - best practice?

[Curtis B.]

Hi folks,

recently, I started working with the STM32H755 dual core processor. With having 2 cores connected to the same peripherals, more opportunities and problems arise.

Currently, I have a setup where I run FreeRtos on the M7 core and bare metal code on the M4 core. I am using CubeIDE with the integretaded code generation tool.

In the first step, I set up UART3 to communicate with a terminal programm on my PC. I use the DMA transfer feature for this UART. Works fine so far, both for transmitting an receiving.

Now I want to transmit data with the M4 core over the same UART as well. In the configuration tool I checked the "runtime contexts" for the M4, too. Initializer is the M7 core:

However, all the neccessary code snippets like IRQ handler, interrupt enabling and so on are not generated for the M4 core. I needed to insert them all manually. To avoid interference between the cores using the same DMA channel to transmit, I used a hardware semaphore which is taken just before the "HAL_UART_Transmit_DMA" function call and released in the transfer complete callback. Moreover I need to enable the DMA IRQ prior to transmitting and disable it in the callback because when the callback on one core is triggered it will not be triggered on the other core and the semaphore will not be released.

With all this code snippets manually botched together it works, but it does not feel like a clean technical solution. Especially having two different UART_HandleTypeDef structures at different memory locations for the same peripheral stresses me out.

Probably it might be better to place the data to transmit in a shared RAM location and give the M7 core a notification to process the data.

Does anyone have dealt with the same issue? What is your opinion on this?

Best regards,

Daniel

[berendi]

The code generator and the HAL library do not cover much of the capabilities of the MCU. What they offer is barely enough to get you started, advanced use cases like yours are far beyond their scope. Do not depend on them, and do not assume that those functions would work properly outside the example projects shipped with the library.

> it does not feel like a clean technical solution. Especially having two different UART_HandleTypeDef structures at different memory locations for the same peripheral stresses me out.

Even having one UART_HandleTypeDef on a single core Cortex-M does not feel like a clean technical solution. The designers of the Cortex-M hardware went to great lengths to ensure that interrupt processing is as fast and efficient as possible, and the HAL library negates all this effort by requiring that all handlers call a common handler function.

There is nothing wrong with either of your ideas to handle this, but I would prefer having one core responsible for each peripheral.

[Tesla DeLorean]

Can't you just have one core manage the peripheral and have two queues in shared RAM ?​

[Curtis B.]

That is the other opportunity I thought about and i think that I will tend to this solution.