Circular DMA interrupts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 5:40 AM
I have a project that uses DMA in circular mode, and i've implemented the half and complete interrupts necessary to manage the transfer. I'm using just 2 nodes, and I've noticed that I get a complete interrupt to start the transfer, and then the expected half-complete-half-complete-etc pattern I'd expect. I've definitely enabled the HT interrupt, but i still always see the TC hit first to start the process.
What is that? Is it a nuance of circular mode?
Solved! Go to Solution.
- Labels:
-
STM32Cube MCU Packages
-
STM32CubeMX
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 7:11 AM
Hello @BDoon.1
What you're observing is indeed a common behavior when using DMA in circular mode, especially when the DMA is first initialized and started.
When you first start the DMA transfer, the DMA controller may generate a transfer-complete (TC) interrupt immediately. This can happen due to the following reasons:
-
Initial State: When the DMA is first enabled, it might consider the initial state as a "complete" state because it hasn't started transferring data yet. This can trigger the TC interrupt.
-
Buffer Initialization: The DMA controller might be initializing the buffer pointers and other internal states, which can cause it to generate a TC interrupt as part of the setup process.
To handle the initial TC interrupt and ensure your application logic works correctly, you can implement a simple check in your interrupt service routine (ISR) to differentiate between the initial TC interrupt and subsequent ones.
Example of how you might implement this in your code:
void DMA_IRQHandler(void) {
if (DMA_GetITStatus(DMA1_Stream0, DMA_IT_TCIF0)) {
// Transfer Complete Interrupt
if (!initialTCHandled) {
// Handle the initial TC interrupt
initialTCHandled = true;
} else {
// Handle subsequent TC interrupts
// Your TC interrupt handling code here
}
DMA_ClearITPendingBit(DMA1_Stream0, DMA_IT_TCIF0);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 5:52 AM
It should work how you expect. You're probably not handling the interrupt in time, or not enabling it in time, or some other race condition.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 6:58 AM
DMA TC isnt same as peripheral TC. DMA TC report you , that last pack (BYTE WORD DWORD) is sended to peripheral. In real use peripherals start for example sending this value same time, in other can place into FIFO exist many variants. But real traffic end is always delayed...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 7:11 AM
Hello @BDoon.1
What you're observing is indeed a common behavior when using DMA in circular mode, especially when the DMA is first initialized and started.
When you first start the DMA transfer, the DMA controller may generate a transfer-complete (TC) interrupt immediately. This can happen due to the following reasons:
-
Initial State: When the DMA is first enabled, it might consider the initial state as a "complete" state because it hasn't started transferring data yet. This can trigger the TC interrupt.
-
Buffer Initialization: The DMA controller might be initializing the buffer pointers and other internal states, which can cause it to generate a TC interrupt as part of the setup process.
To handle the initial TC interrupt and ensure your application logic works correctly, you can implement a simple check in your interrupt service routine (ISR) to differentiate between the initial TC interrupt and subsequent ones.
Example of how you might implement this in your code:
void DMA_IRQHandler(void) {
if (DMA_GetITStatus(DMA1_Stream0, DMA_IT_TCIF0)) {
// Transfer Complete Interrupt
if (!initialTCHandled) {
// Handle the initial TC interrupt
initialTCHandled = true;
} else {
// Handle subsequent TC interrupts
// Your TC interrupt handling code here
}
DMA_ClearITPendingBit(DMA1_Stream0, DMA_IT_TCIF0);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 9:06 AM
Which STM32?
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 11:11 AM - edited ‎2024-08-21 11:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 11:52 AM
This is on an STM32U585QI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-21 11:53 AM
Thanks! Is there a good way to configure the DMA so it doesn't throw this initial TC interrupt? Or a way to tell which linked list node is active when the HT hits, other than keeping track of what I think it should be?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-22 12:31 AM
Ar @TDK said above, this is definitively not normal on the "traditional" STM32 DMAs. 'U5 has a brand new GPDMA which is way more complex, and if it does this, it's definitively a flaw, but apparently you'll have to learn to live with it.
I don't use the 'U5 but unless you program the GPDMA yourself, you may want to read out and post the GPDMA registers just before enabling it, for anybody who would like to try to reproduce it.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-22 7:43 AM
I strongly question the validity of the reply with regards to TC already being set on startup. I would recommend verifying that behavior is accurate.
