STM32G070 DMA memory to memory software trigger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-11 09:06 AM
Hi,
I have read thoroughly RM0454, STM32G070CB datasheet and AN4187 in order to understand how to configure the DMA and DMAMUX in order to feed the CRC peripheral with FLASH data using the DMA (with CPU it is working but way slower than expected).
I don't understand how to start the DMA requests through software, is there anyone who had successfully done it on G0 ?
P.S. I don't do Cube and I don't want to do it for various reasons...
Solved! Go to Solution.
- Labels:
-
DMA
-
STM32G0 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-11 09:23 AM
Hello,
You can inspire from the following example: https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Projects/NUCLEO-G070RB/Examples/DMA/DMA_FLASHToRAM
and you need to change some DMA parameters to fit your need.
PS: DMAmux config is done in HAL_DMA_Init()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-11 09:23 AM
Hello,
You can inspire from the following example: https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Projects/NUCLEO-G070RB/Examples/DMA/DMA_FLASHToRAM
and you need to change some DMA parameters to fit your need.
PS: DMAmux config is done in HAL_DMA_Init()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-11 09:24 AM
P.S. I don't do Cube and I don't want to do it for various reasons...
You can at least inspire from it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-12 12:45 AM
Hello @SofLit
Thank you for the (very) fast answer.
It was cumbersome because I had to look through the G0 CUbe github repo for HAL_DMA_Init() (thank you for the hint).
Really I would like to stress that the DMA documentation for the new parts (the ones with DMAMUX) should be rewritten, the documentation shall help to create the source code, not the other way around.
For those who don't do Cube like me, the answer is that for memory to memory mode and software trigger, the DMAMUX channel related to your DMA channel should be configured as 0,
i.e. for DMA1_Channel1 you should write DMAMUX1_Channel0->CCR = 0;
Then the DMA transactions are started as soon as you enable the DMA channel,
i.e. DMA1_Channel1->CCR |= DMA_CCR_EN;
I divided by 3 the time taken to compute the CRC of 20 480 bytes of flash with the DMA (526us) compared to without.
The theoritical CRC computetime is 320us at 64MHz HCLK, I guess I have some overhead due to the DMA feeding the CRC, and/or the CPU checking the DMA flag that stall the DMA (?).
Best regards,
Kraal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-12 02:42 AM
> the answer is that for memory to memory mode and software trigger, the DMAMUX channel related to your DMA channel should be configured as 0,
Oh, so if the respective DMAMUX is set to some of the peripherals (i.e. nonzero DMAMUX_CxCR.DMAREQ_ID), M2M DMA won't start? Or perhaps it will start if a trigger arrives from the respective peripheral?
Thanks for this information.
In this case, the description in RM is not only insufficient, it's straight incorrect.
@SofLit, can please providing correct and complete information in documentation be prioritized before pointing to example code?
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-03-12 02:59 AM - edited ‎2024-03-12 03:00 AM
@waclawek.jan
good call, I had not read the RM hard enough, apparently.
I would suspect that it would wait for the peripheral trigger, but I will test for certainty.
I will try to test that as soon as possible...
Best regards,
Kraal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-07 02:42 AM
Hi @Kraal ,
I tried to reproduce your finding on a 'G0B1 Disco, but was not able to.
In attachment the source. DMAMUX is set to TIM2_UP, and TIM2 is set to overflow once in a second (there's also an ISR to toggle a LED upon TIM2_UP, for visual clue).
If the non-MEM2MEM option is used, observing the dst array in debugger shows, that every second, one more member of that array changes from 0x55 to 0x22 (DMA1_Channel1.CNDTR is decremented accordingly, too).
If the MEM2MEM bit in DMA1_Channel1.CNDTR is set, all members of dst array change to 0x22 immediately, regardless of what is in DMAMUX1_Channel0_CCR.DMAREQ_ID.
Can you please comment, or post your version of code which does exhibit the problem?
Thanks,
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-08 04:50 AM
Thank you for testing on your side, the RM is correct.
My initial misunderstanding was about the setup of memory (FLASH) to peripheral (CRC) DMA transfer with software trigger.
I was missing the MEM2MEM bit, and since I did not read carefully enough the RM, I was trying to find what DMA_MUX settings would correspond to a software trigger or something related to the CRC peripheral.
My apologies for the confusion and the time you spent on this matter.
Best regards,
Kraal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-08 09:52 AM
Hi @Kraal ,
thanks for the clarification.
Btw., it was time well spent - I've never played with DMAMUX before, so this was a good motivation to try it... :)
JW