LPC82x DMA ch trigger and behavor after trigger

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

LPC82x DMA ch trigger and behavor after trigger

1,205 次查看
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,
标签 (1)
0 项奖励
回复
3 回复数

743 次查看
lpcware
NXP Employee
NXP Employee
bump
0 项奖励
回复

743 次查看
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 项奖励
回复

743 次查看
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 项奖励
回复