From the specification exert below, I understand, that setting FIFO enable to 1, enables also the DMA Mode. Does it mean the DMA Mode operates "automatically"? I cannot see a relationship, that I have to configure the DMA in some way. In other ways, how should I read the below specification regarding operating or not with DMA?
"UARTn FIFO Control Register Bit Symbol 0 FIFO Enable 1 Active high enable for both UARTn Rx and TX FIFOs and UnFCR[7:1] access. This bit must be set for proper UART operation. Any transition on this bit will automatically clear the related UART FIFOs. 3 DMA Mode 1 When the FIFO enable bit (bit 0 of this register) is set, this bit selects the DMA mode 4.6.1 DMA OperationThe user can optionally operate the UART transmit and/or receive using DMA. The DMAmode is determined by the DMA Mode Select bit in the FCR register. This bit only has anaffect when the FIFOs are enabled via the FIFO Enable bit in the FCR register. UART receiver DMA In DMA mode, the receiver DMA request is asserted on the event of the receiver FIFOlevel becoming equal to or greater than trigger level, or if a character timeout occurs." UM10360LPC17xx User manualRev. 01 — 4 January 2010
"UARTn FIFO Control Register
Bit Symbol
0 FIFO Enable 1 Active high enable for both UARTn Rx and TX FIFOs and UnFCR[7:1] access. This bit must be set for proper UART operation. Any transition on this bit will automatically clear the related UART FIFOs.
3 DMA Mode 1 When the FIFO enable bit (bit 0 of this register) is set, this bit selects the DMA mode
4.6.1 DMA OperationThe user can optionally operate the UART transmit and/or receive using DMA. The DMAmode is determined by the DMA Mode Select bit in the FCR register. This bit only has anaffect when the FIFOs are enabled via the FIFO Enable bit in the FCR register.
UART receiver DMA
In DMA mode, the receiver DMA request is asserted on the event of the receiver FIFOlevel becoming equal to or greater than trigger level, or if a character timeout occurs."
UM10360LPC17xx User manualRev. 01 — 4 January 2010
Nothing just works "automatically". But I am sure there are plenty examples for the LPC17xx with UART and DMA. Just check your favorite web search.
Web search might help or not. Rather the question is about interpreting the specification (the only reliable source). (And "automatically" was meant ironically).
ArmAsking said:the question is about interpreting the specification
But that has nothing to do with ARM: it is NXP's IP, and NXP's specification - so you need to ask NXP for any clarification of their documentation.
https://community.nxp.com/
For the distinction between what;s ARM's and what is the chipmaker's, See:
https://community.arm.com/developer/tools-software/tools/f/keil-forum/43684/lpc2148-timer0-not-working-as-expected/158950#158950
As others have suggested you definitely need to ask this sort of question on the device manufacturer's forum to get a specific reply.
However just based on what the above spec quotes say, if you enable the UART FIFOs this then allows you to specify whether the UART then uses DMA requests to service the UART FIFOs, or else perhaps just uses interrupts to control FIFO access requests. These DMA requests, if enabled, will be generated when the UART FIFO contents pass trigger points indicating when data needs to be read from the RX FIFO or written to the TX FIFO, the aim then being to keep the FIFO contents updated to allow constant serial comms.
As to what the FIFO trigger levels are, or what DMA request types might be generated, and how they might be configured, those are the details you would need to find elsewhere in the device's documentation, or by contacting the aforementioned manufacturer forums.
I think that's about the most you could expect anyone here to determine based on the documentation segment. Hopefully it agrees with what you have understood, and what you subsequently get from the manufacturer's documentation or forums.
Hi Colin. I'm having the same need and device manufacturer's (Atmel) TRM's are lacking. Atmels forums for ARM are unfortunately not as active and the few answers existing are clobbered with irrelevant information. So my hopes is on ARM for this. It seems that the device in our case (SAME70J21 a Cortex-m7) does not have FIFO's for UART, yet it has DMA support (?). My understanding is that one would use DMA to transfer a packet to the FIFO, the start the UART transfer which would then continue until the block is transferred autonomously. Is the Atmel documentation lacking or is my understanding incorrect? If it's lacking, one may perhaps assume that what's missing is actually generic enough to qualify as a topic for ARM.
Michael, I wish I could help you here, but only Atmel know how their device works. Their chip might have an ARM Cortex-M7 inside it, but that wouldn't then mean we (ARM) know what is in the rest of the chip.
How the UART and DMA interact wouldn't usually be something the Cortex-M7 is involved in. The Cortex-M7 might be the bus master that configures the DMA and the UART in the first place, but the usual idea of having a DMA is that it then takes the load off the main bus master, freeing it up to do other tasks while the DMA moves data around.
If their UART doesn't include FIFOs, but does have a DMA interface, I would guess that DMA accesses would only be to read or write ONE value to/from that UART, rather than something a bit more DMA-sensible like having a buffer/FIFO in the UART that can handle bursts of DMA transfer.
So either the DMA is configured to transfer SINGLE data at a time, or the DMA can be used to transfer a burst to/from the UART, but the connection between the DMA interface and the UART is then stalled while the UART slowly completes that requested DMA "burst".
But I'm as much in the dark as you are, probably more so as I've never looked at the Atmel device's documentation - actually out of curiosity I have now had a look at the datasheet for this device to see what it says, but I didn't learn anything that would change any of the above.
The Atmel MCU is based on the ARM Cortex-M7, but the M7 is just one small (but important) building block in the larger MCU, so that level of system knowledge is something only Atmel can help with.
If you are not getting any response from Atmel's forums, do you have a distributor supplying you with the MCU that you can pressure, or do you have any Atmel FAEs you can contact ?