STM32H7xx DMA interrupts not working on UART receive

Requirement:

Receive every byte of data over uart, as I need to look for \r and then process numbers before it, use interrupt driven code for better resource usage.

What I have tried:

Enable uart in cubeMX, add DMA request for uart in circular mode.

Then in simulink, I added a Hardware Interrupt Block and selected the DMA channel, which i set for uart, as interrupt source. I am checking only 'TC' event as interrupt source in hardware manager block.

Issue:

The code compiles and runs without error. But the triggered subsystem(function call) connected to Hardware Interrrupt Block never runs since my values counter never increments in the subsystem. I think that DMA is configured but it is not started properly by simulink to generate interrupts.

I have tried using Hardware interrupt block with External interrupts from button push, in that case, my interrupt driven counter increments. But when switch interrupt source to the DMA attached to uart RX, no interrupt occurs.

Question:

Has anybody any idea how can I generate interrupts from DMA block when it receives one word (4bytes) from UART and use the Hardware Interrupt block to call my triggered subsytem to process those bytes.

Thanks.

Answer 1

[Nithin]

Currently, the Embedded Coder Support Package for STM32 does not support the usage of the hardware interrupt block configured with the DMA channel that is being used by the USART module. The DMA transfer complete interrupt is used internally to receive data into the buffer. You should get an error in the Diagnostic Viewer which looks like that shown in the image below:

In your case, I suspect that this error did not show up because the USART module was not configured to receive data in DMA mode. This setting is done in the model's Configuration Parameters:

By default, the Receive mode is set to "Buffered mode using RXNE interrupt", thus data was being received in interrupt mode rather than DMA mode. Setting the USART_RX DMA channel in STM32CubeMX is not enough. This is also why the hardware interrupt block in your model did not work as expected.

In order to achieve your modeling scenario, you could perhaps connect the output of the USART Read block to the input of the Protocol Decoder block. You can set the header and footer in the latter and receive your data accordingly.

Hope this helps, do let us know if this approach works for you.

[Gheorghe Lisca]

How could we change the block/code inside the block itself, to reflect the changes we need. ?

This a serious oversight by the creator of that block..

More to this... since there is already the option of ""BUffer using DMA" ...why does it not get triggered?

[Nithin]

At present it is not possible to make changes to the block. We have taken a note of this requirement and will be handling this in future releases.

Answering the second part of your question, the DMA transfer complete interrupts are used internally in the driver code for the block if the "Buffered mode using DMA" selection is made. As a result, the corresponding DMA transfer complete interrupt cannot be used as a hardware interrupt block, but this interrupt does get triggered.

[Shahzad Anwar Khan]

@Nithin Thank you so much for clarifying the DMA feature for the UART. You are right, I also got the error in earlier phases when i changed config settings of the UART receive mode from 'buffered mode using inerrupts' to 'buffered mode using DMA'. From that error, i was obvious that I can't use DMA at a time for uart buffered mode in config settings and DMA as a interrupt source in Hardware Interrupt block.

That's why i was focusing only on getting the Hardware Interrup block get triggered by DMA TC interrupt but as you pointed out, that will not work because UART is working in its own interrupt driven buffering, thus bypassing DMA.

I will look into the Protocol Decoder as you suggested.

Answer 2

[Umar]

Hi Shazam,

My suggestions would be to verify that the DMA channel is properly linked to the UART and that the interrupt source is correctly selected in Simulink.Also, check the DMA settings, such as buffer size and triggering conditions, to ensure that interrupts are generated when data is received. Additionally, confirm that the Hardware Interrupt Block in Simulink is configured to respond to the correct interrupt source from the DMA channel associated with UART reception.

By carefully reviewing the DMA and interrupt configurations in Simulink, you can troubleshoot and resolve the issue of generating interrupts from the DMA block when receiving UART data for efficient interrupt-driven processing.

Hope this will help resolve your issues.

Answer 3

[Gheorghe Lisca]

How about some really technical explanations ? THis post by UMAR sheems absolutly shallow.

Of course we checked all the steps from this list. WHat does "Becarefull when DMA/int " even mean?? Be real.

I have been fighting with the same issue for a a few weeks and cannot make it work.

[Umar]

Gheorghe,

Please see response from Nithin. I was trying to help. Please let us know if you have further questions.

Answer 4

[Gheorghe Lisca]

Hi @Nithin

Was wondering if this problem was solved with the lastest update of Simulink in M 2024 B?

We also tried Protocol deCODER, but we have no header in the UART message, so still waiting for you guys to fix the issue initially presented.

[Nithin]

Hi Gheorge,

This has not been addressed in R2024b.

[Gheorghe Lisca]

Any feedback when is realistically gonna be changed?