1) When the DMA/TD is configured to require a DMA request for each transfer, then supressing the DRA signal will stop the DMA.
2) you can read the current target address from the TD.
Thanks for the responses. I've implemented and tested, and you are indeed correct on number 1: suppressing the signal stops the DMA requests from triggering bursts, which stops the DMA and it's associated TDs from continuing to operate.
However, I've been having a lot of trouble with 2),
CyDmaTdGetConfiguration(MyTD, TransferCount, nextTD, Configuration)returns the initial transfer count (in my case 2048) and not the current transfer count. The same happens with
CyDmaTdGetAddress(MyTD, &SourceAddres, &DestinationAddress)where my destination buffer's address is 0x1fffa2c4, and the TD returns 0xa2c4, which is the initial address and not the current address. The DMA is running in real time and I haven't seen any differing output.
Is there something I'm missing?
When you look at the "advanced DMA" application note, there are examples of how to modify a TD dynamically (by setting the addresses). This could be reversed, so this AN could give you a hint of how to proceed. I'm not sure whether the API methods read the actual values or the configuration that has been set.
Hmm, I'm taking a lot, but running into a lot of issues.
First, because of the way transfer counts work, I can't easily add a second TD that points to the DestinationAddress field and outputs that to another variable in RAM, because my ring buffer TD has to have a transfer length large enough to fill the entire ring buffer and it doesn't go to the next TD until all the ring buffer is filled. This defeats my purpose. It looks like to make this work, I would need to make a very complicated DMA arrangement that handles the ring buffer activity in a complex way, where it sends an interrupt every time the buffer is full to reset the base address to the first address, which in a free running situation seems fraught with risk of buffer overrun.
A simpler solution seems to be accessing the TD registers directly and reading from there after I've paused the DMA, as I can use the same DMAC_TDMEM[Storage_DMA_TD].TD1 call as the chaining DMA calls use directly in my code.
But this just leads to the REAL problem, which is that the DMA register values do NOT seem to update with the execution of the DMA. I don't know where it's tracking the decrease of the transfer count, and the increment of the source address, but it's not done in the DMAC_TDMEM location, as those values in memory do not change from the configuration during exectuion. I can watch the memory addresses where transfer count and destination address are stored from the DMAC_TDMEM[Storage_DMA_TD].TD1 call, and they do not change over time.
Are there tools for watching the memory values within a range for a specific value, such that I can try and run the program and figure out what memory location the DMA is using for it's internal counting, then I can try and backtrack through their struct sizes to figure out a safe way to reference that location?
When I read the Registers TRM correctly, DMAC_TDMEM[Storage_DMA_TD].TD1 access the upper 8 bits of the destination address. Does this change for your setup? Maybe you need to use DMAC_TDMEM[Storage_DMA_TD].TD1? The transfer count is in .TD0/.
I managed to figure it out after watching the program ram in debugger and setting up a number of tests.
You are partially correct on that, though TD1 seems to be the most significant bits and TD1 the least significant bits (must be the endianness of the memory). Both are necessary to get the lower 16 bits of the address,
However, that doesn't cover the real issue, which is that using
DMAC_TDMEM[Storage_DMA_TD]moved to a location in the TD queue where the default values appear to be kept and stored (at least in my case where I have preserve initial values enabled, so I don't need to manually reset the starting point each cycle). The actual real time values from the execution of my two DMAs are located in
(DMAC_TDMEM.TD1 << 8) | DMAC_TDMEM.TD1successfully fetches the lower 16 of the current destination address. Likewise, the remaining transaction count is in TD0 and TD0.
I think it's a result of this behaviour of the Preserve function:
"If TDs are preserved, the channel uses a separate TD memory (corresponding to the channel number) to track the ongoing transaction; otherwise the original TD configuration registers are used as working registers to track the ongoing transaction." So my DMA 0 uses TD channel 0 for the running memory, and likewise with TD1, and my actual TDs like Storage_DMA_TD which gets allocated to me is allocated at the end of the list as TD 0x7F where they are preserved. I think I misread and assumed that the special register was used to preserve the settings and the normal was still tracked the ongoing progress, but thinking about the implications that would entail I see why it's not the case.
Now I just need to see if the DMA Channel variable gets the value of 0x00 or 0x01 in order to more safely access the correct TD memory struct, but hard coding will also work as long as I don't change the order in which the DMA are instantiated.
Thank you very much for your help in figuring this all out.
One debugging tool often used is to initialize your data buffer with a repetitive sequence of hex values such as 0xFEEDBEEF or CCCC. It is easy to see what gets overwritten and what does not.