How can I add DMA to both cores on STM32H7 dual core MCUs

[Mfail.1]

Hello Guys,

I am using a STM32H755ZI and I learned a lot about this MCU the past last months. However I am struggling with DMA.

I got DMA working on one core, but I would like to use DMA on the same peripheral on both cores. I got it kinda working, but it messes some things up. What I did, was that I initalized everyting the same on the both cores, so same Peripheral Interrupt, same Dma interrupt. It works actually, but it messes with my tasks, as I am running Freertos on both cores.

Could you please tell me, how I have to initialized it correctly, such that I have DMA working on both cores for the same Peripheral e.g UART or SPI

Thank you guys,

Marco

[Tesla DeLorean]

Really not how this is supposed to work.

Typically you'd pick ONE core to manage the peripheral and it's DMA/IRQ, and partition your design appropriately.

If you want multiple cores or processes to share are resource you'll need to have some mutex/semaphore to arbitrate current ownership of responsibility.

[Mfail.1]

Thank you for your fast response.

Okay, I have to keep that in mind, thank you for pointing it out.

I tried out the hardware semaphore. Do you have an example how I could implement it in this case?

But I am still wondering. I have set up the DMA/IRQ on both cores for UART, but I use it on just one core to transmit something to my pc. It works, however after a while the uart stops transmitting even though just one core is using it.

[Tesla DeLorean]

>>But I am still wondering. I have set up the DMA/IRQ on both cores for UART, but...

Why?

It's like having two drivers fighting over control. You're going to have continual race conditions over who can response first.

Pick one to own the peripheral, and build buffering such that each can submit content to an outgoing queue. That way it won't break, or randomly interleave the data.

Does your algorithm need to control the UART in two places?

[Mfail.1]

Both cores have different tasks and we separated them such that one core takes over the vehicle control and the other the battery management. The idea behind that was to have a more separted structure. So it would be nice if both cores could write something to the "console", but actually we could improve the algorithm, such that just one core owns the peripheral.

Thank you for your answer

[berendi]

DMA and UART are independent of the cores. They can be controlled by any one of the cores, or both, but then the drivers must take this into account. HAL was not written with that in mind. If you want to control a peripheral by both cores, read the relevant chapter of the reference manual thoroughly, be sure that you understand all the implications, especially the possible race conditions, then write your own driver. Do not even think about attempting it if you do not know what a race condition is.

On the other hand, both cores have their own interrupt controller. If a peripheral triggers an interrupt which is enabled on both cores, then both cores will start their interrupt handlers. However the interrupt handlers are not started at the exact same time, and do not run at the same speed. They are started on each core when it is ready to be interrupted, and are competing for the same resources, with results that are next to impossible to predict accurately.

[Mfail.1]

Thank you for your explanation! It really helps a lot

I will not write my own driver for now. First because I don't have the knowledge right now and second because for this application I don't have the time to learn all those things and write a driver in time.

I don't know if it is a kind of a stupid question but why does CUBEMX lets me initialize the Peripherals on both cores and further, can't I use the Hardware Semaphore (HSEM) to control the peripheral, so they don't get messed up. What I was thinking is that I could give the Semaphore back, wenn the message got transmitted.

Or for what is the HSEM used? To just control reading and writing on a shared memory?

[berendi]

> why does CUBEMX

What CubeMX does is only known to its authors (and sometimes it seems even they have no idea). You click somewhere and something happens. If you update it to another version, then maybe something else happens.

You should never trust CubeMX that it does what you think it should do. It does, some of the time, but you can never be sure. Way too often its authors make assumptions that are different from yours.

CubeMX helps you to create a prototype that initializes some peripherals in more or less sensible ways. The generated code is however full of code constructs that should never make it into production code. Its only use is to get some basic things running, to have a partially initialized system where some peripherals already do something, so you can replace the generated code and the HAL functions with something sensible.

Speaking of HAL, most of the above holds for it as well. There is only a token effort that went into documenting it, so HAL functions might or might not do what you think they should do. They usually work if they are used exactly as in the example projects. They fail in subtle ways on advanced MCUs like the STM32H7. They were never written with a dual core MCU in mind. Sometimes they fail in not so subtle ways. Seriously, how could one trust a library which can not even get toggling pins right?

If something in CubeMX or HAL does not work, you can either change settings or parameters randomly, or read the actual documentation in the reference manual to understand how a certain peripheral is supposed to work. You have already wasted more time trying to figure out what settings would make some peripherals work the way you want them, than it would have taken to read the relevant chapters of the reference.

[Mfail.1]

Okay, I figured that CubeMX does stuff that i shouldn't do. This is why, we are using it less and less. But I didn't know that the HAL Library is this bad.

We tried reading the actual, or we are reading those. And I thank you for opening our eyes, when it comes to HAL and CubeMX. However we are two students that actually study mechanical and electrical engineering and are supposed to write a software in a motorcycle for a university project. We are both VERY new to this kind of stuff. How are we supposed to know that? I mean, we had to choose even the Hardware by our own, with no explanation or someone who has the slitest idea, explaning things. I mean it is no excuse, what I am trying to say is we are learning along the way everything from scratch. It's hard but there are some good lessons we learned.

Again, thank you for your reply, I take those things with me! But we really don't have the time to write every driver by our own.

[Nikita91]

"How are we supposed to know that?"

As students you are supposer to learn that.

Here you are learning the reality of the industrial world. In this context, learning how to do something is more important than doing it.

Now spend time understanding and debugging CubeMX and HAL, instead of writing your own code, it's your choice.

[Mfail.1]

Yes and I am thankful for your answers. I do get that we made mistakes. Isn't this how learning goes. Making mistakes and improving and learning on those.

We are mostly out of CubeMX, we learned that the hard way. With HAL it is a different story. But I see your point and I'll take a look.