SparkFun Forums

[fpm]

I'm trying to use DMA to transfer data from memory to a UART. I'm using lots of CMSIS code. When DMA didn't seem to work, I stepped through the library code. In the CMSIS function GPDMA_Setup(..), about half way through a number of values are bit-OR'd together to set the pDMAch->DMACCControl word value. No matter what value I use for the transfer size, those bits appear zeroed when examining the Control word value. I have altered the code, including ORing the values into a temporary variable (which works correctly, the transfer size is in that) then setting DMACCControl=temp_val. This sets all the bits of DMACCControl _excepting_ the transfer size!

I've tried two different boards (with different chips) and tried different DMA channels - same results. I've scoured the NXP manual looking for some kind of protection for these bits and found none - besides, the code is much like the UART-DMA example included with the CMSIS code - which couldn't be wrong, could it?? The most recent errata sheet that I had from NXP lists no DMA problems.

Might there be something systemically wrong with the chips (that NXP hasn't revealed, yet) or a very weird problem with the OpenOCD/Olimex-ARM-USB-OCD debugger? These seem unlikely too.

I'm stumped at this point. If anyone has a clue, I'd appreciate it!

-f

[TCcnc]

DMA operation on NXP LPC17xx is poorly documented. Everyone gets confused. You didn't describe the details of the DMA you are trying to set up so it isn't really possible to help you.