LPC82x DMA ch trigger and behavor after trigger

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

LPC82x DMA ch trigger and behavor after trigger

893 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by S.Kojima on Sun May 08 19:36:33 MST 2016
Dear fellows,

I'm trying to use LPC824's DMAC triggered by SCT's DREQ signal.
But, no in success yet.

The description for the DMAC channel is ...
Destination is one of SCT's MATCHREL[n].L, a fixed address
Source in ROM two different values to update MATCH value alternatively by those two values.
So, SRCINC=1 while DSTINC=0.
To repeat this update sequence, the next field of the descriptor points back itself.
Of course, PERIPHREQEN=0, HWTRIGEN=1 to accept trigger, disabling peripheral request.
TRIGBURST=0 for step-by-step sequence at every trigger.

Unexpected behavior that I'm watching now is...
once the DMA ch is triggered, it starts updating sequence, but at unexpected update timing
regardless of the hardware trigger timing and sequence never stops until the DMA channel is disabled.

Before supplying hardware trigger, I tested software triggering thru uVision debuger.
PERIPHREQEN=0, HWTRIGEN=0 to disable any hardware req and trig.
Descriptor setting is as same as above.
After enabling that DMA ch, I give a trigger to that DMA ch thru SETTRIG register.
Then, that DMA ch starts working thru the descriptor sequence. But, never stops.

The descriptor execution and each DMA transactions are correctly made as I coded.
The only strange thing is the response after accepting the first trigger.
That DMA ch seems doing the transfer activity at full-speed even I gave just one trigger.
Maybe, this is the essential cause that I've experienced with HW-trigger by SCT.
I think I should solve this simpler one first, before I go forth with HW-triggering.

But, I have no idea what is wrong.

Regards,
Labels (1)
0 Kudos
3 Replies

431 Views
lpcware
NXP Employee
NXP Employee
bump
0 Kudos

431 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by S.Kojima on Sun May 08 21:23:50 MST 2016
Dear fellows,

A little progress.

My "unexpected" behavior reported in my previous post seems like...
as if I made a mistake to program a DMA transfer behavior as BUSRT.
Just as a stupid trial, I set TRIGBURST bit opposite as the user manual expains.

Then, I found it works as I expected.
The actual implementation of DMA block seems to be made wrong....
If so, it would be an errata.
I set TRIGBURST as 1 (not cleared as 0) to get non-burst (trigger-by-trigger) transfer.

I did not tested neither in the other application nor the family MCU chip with
the same DMAC, such as LPC11U6x.

I would like to ask an NXP staff to check and confirm the actial implemeation
of this DMAC.
And, I would like to wait for the official report for this issue by NXP.

Regards,
0 Kudos

431 Views
Carlos_Mendoza
NXP Employee
NXP Employee

Hi S. Kojima,

As discussed by email with Yoshinari Kohara , there are no know problems with TRIGBURST bit so the behavior might be related with the DMA configuration. I would recommend you to use the Example_DMA_UART project, this example is intended to demonstrate the usage of the DMA controller with linked descriptors, peripheral DMA requests and triggers. It also provides a clear framework upon which more complex configurations of the DMA controller can be built.

It can be downloaded from the LPC82x example package from this link:

https://community.nxp.com/community/lpc/blog/2016/09/02/lpc8xx-family-code-example-bundles

Let me know if there is any doubt or question.

Best Regards,
Carlos Mendoza
Technical Support Engineer

0 Kudos