Hello,
in the attached project an eDMA Major Loop gets triggered after enabling peripheral requests in eDMA channel 0 despite no PIT trigger events occurred and therefore the first data is lost.
The example simply copies the first 10 elements of sourceBuffer
to the first 10 elements of destinationBuffer after a PIT CH0
trigger (every 0.5 seconds) and fires an interrupt when finished.
Every ISR run increments a counter.
After the interrupt fired the buffers and the counter are printed to the
DEBUG console. Afterwards the counter gets reset to 0 and the source buffer
gets initialized with new data.
The buffers are double the size in order to check correct eDMA settings.
1. Initial setting as attached to this post
The MCUXpresso Config Tool Peripheral setting for eDMA CH0 request is set
to DMAMUX always on.
Because of this setting the first eDMA Major Loop
transfer will be triggered after the function call
EDMA_EnableChannelRequest(DMA0_DMA_BASEADDR, DMA0_CH0_DMA_CHANNEL);
in peripherals.c line 181 despite the HRS register of DMA0
not showing any hardware request. If you take a look at the TCD0_SADDR and
TCD0_DADDR you see that the set values are correct before executing above
function. After executing and enabling the channel request SADDR and
DADDR get incremented by one and now show to an incorrect address.
The first expected data of 0x00 will not be transfered after the PIT channel
is started in main. Every following Transfer works as expected.
2. Now change the MCUXpresso Config Tool Peripheral setting for eDMA CH0
request to DMAMUX disable and update the code. The DMAMUX will be enabled
before the PIT is started in main.
This way everything works as expected. The first data 0x00 gets transfered
to destinationBuffer.
The init function is not following the Initialization chapter for DMAMUX of RT1020 Reference Manual.
The chapter states that you first have to properly set up eDMA and PIT
and afterwards enable DMAMUX.
Is the DMAMUX/eDMA/PIT initialization order incorrect in Config Tools v7?
Why is a eDMA transfer triggered in 1 if we enable DMAMUX first?
Kind regards,
Stefan
Solved! Go to Solution.
Hello,
in the attachment, there is hotfix for your issue. Please, follow the instructions inside the package.
Best regards
Martin
Hello Martin,
he hotfix works. Thank you!
Kind regards,
Stefan
Hello Stefan,
I am sorry for the late reply.
I checked your code and it seems that the issue is when DMAMUX_EnableChannel is executed before DMAMUX_EnablePeriodTrigger. If you switch the order of this APIs you will get correct behaviour.
Please check the following note from the reference manual chapter 4.6.1.2.2:
Before changing the trigger or source settings, a DMA channel must be disabled via CHCFGn[ENBL].
I hope this helps!
Best regards,
Felipe
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hello Felipe,
thank you for your answer.
The code is generated by MCUXpresso Config Tools. Will this get fixed in the next Config Tools release/ will there be a hotfix for it?
Kind regards,
Stefan
Hello Stefan,
thank you very much for your feedback! The function call order will be fixed in the following Config Tools update and I prepare the hotfix as well.
Best regards,
Martin