Is the DMAMUX/eDMA/PIT initialization order incorrect in Config Tools v7?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Is the DMAMUX/eDMA/PIT initialization order incorrect in Config Tools v7?

Jump to solution
1,451 Views
mitterha
Senior Contributor I

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.

  pastedImage_1.png
  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

Tags (3)
0 Kudos
1 Solution
1,264 Views
martin_stano
NXP Employee
NXP Employee

Hello,

in the attachment, there is hotfix for your issue. Please, follow the instructions inside the package.

Best regards

Martin

View solution in original post

5 Replies
1,265 Views
martin_stano
NXP Employee
NXP Employee

Hello,

in the attachment, there is hotfix for your issue. Please, follow the instructions inside the package.

Best regards

Martin

1,264 Views
mitterha
Senior Contributor I

Hello Martin,

he hotfix works. Thank you!

Kind regards,

Stefan

0 Kudos
1,264 Views
FelipeGarcia
NXP Employee
NXP Employee

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.
-------------------------------------------------------------------------------

0 Kudos
1,264 Views
mitterha
Senior Contributor I

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

0 Kudos
1,264 Views
martin_stano
NXP Employee
NXP Employee

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

0 Kudos