K64 SPI - DMA - missing a byte on transfer

[JHinkle]

I have implemented a detection and recovery method - but I would like to understand root-cause of the issue.

Two mcus communicate via SPI.  The K64 is the slave.  The master's spi clock is 8mhz.

69 byte Data packets are passed between the two mcus with an external IO pin being used for handshake/flow control.

The K64 (cpu clock is 120mhz) uses DMA to receive the incoming 69 byte packet and fire an interrupt upon completion.  Upon processing the packet, the flow control pin is toggled signaling the master to send another 69 byte packet.

Issue:  I can receive tens of thousands of these packets without an issue.  Then randomly, the process stalls and the stream of packets is halted.  Investigating the issue I found the K64 failed to acquire one of the bytes in the packet and the DMA counter is at one - so the DMA IRQ never fires.

Is there a known SPI hardware issue that may be causing this?

I have implemented a timeout detection process which resets the SPI's DMA channel and requests the last data packet be resent by the master.

As a side note - question #2.  The DMA documentation on the K64 states that once the DMA is engaged, the DMA channel can't be stopped until the inner DMA loop is completed.  It also states that CX in the DMA_CR register can be used to cancel the remaining data transfer.  My question is why is this not a per channel operation instead of one that is global to all channels.  In my case, I have two active dma channels in operation, so when I activate CX to kill the data transfer of my SPI-DMA receive process, I am also affecting the transfer of the other channel.

I found zero information being documented on how to recover from a failed DMA transfer.  After a lot of reading and trying different methods to stop the transfer (CX above) - I was able to reset the channel and continue with the flow of my data packets.  I suggest NXP think about adding some fault recovery documentation.

Third question/comment.  At first I was unable to reset the SPI's DMA channel - so after 10 hours of work I decided to use SPI interrupts instead of DMA.  I found time to reply to the IRQ and return was longer than 1 usec so I had to stay within the IRQ function and poll the SPI_SR RFDF status bit or I would get a SPI overrun condition SPI_SR - RFOF being set.

The K64's documentation states the the SPI_SR RFDF would fire an interrupt if any of the 4 FIFO locations was filled.  My testing suggested that the IRQ is not firing until the FIFO has more than one location filled - is that true?  The documentation also states that writing a one to the SPI_SR RFDF bit will reset it (which is what I did after each read of the SPI_POPR).  If there is more than one location filled in the FIFO when a POPR - Set RFDF operational pair is performed, will the K64 reset the RFDF bit immediately since the FIFO is NOT empty?  These are questions I was not able to determine based on code execution since I was unable to acquire all 69 data bytes without issue using polling.  I went back and finally figured out how to reset the DMA channel.

I know I asked a lot of questions in this post but they all came up in trying to understand why the K64's SPI/DMA would occasionally miss a data byte.

Thanks for any comments.

Joe 

[JHinkle]

Thanks for your comments Dave.

The two micros are on the same pcb so no trace/connection concerns.  The SPI clearly shows that a data byte was not acquired by DMA prior to the next one coming in.

Micro1 has access to a 65meg data file that it must pass to micro2 for processing.  The transfer process breaks the 65 Megabytes into 64 byte blocks and transfers them via SPI where the K64 is the slave in this case.  Block transfer is flow controlled by another IO pin --- which means it takes about 1,000,000 block transfer to move the data.

The issue is if I do approx 10 complete 65MB file transfers, one 64 byte block out of the 10 million blocks transferred will have this issue - trying to find out what could affect DMA to miss the SPI request to transfer data.  Currently I have direct traces for the SPI signals between the two micros - I did not consider 8 mhz clock that fast to add inline 50 ohms resistors to help control transmission line affects -- which I may do in the next board turn.

I questioned CX because it is part of the CSR register which affects all channels.  The documentation states that setting the CX bit will make the DMA assume it completed its TCD task.  I did find that the CX bit did not seem to work on a channel if the channel was enabled.  In my recovery function, I disable the channel, set the CX bit and then wait for it to go to zero, then enable it -- which works.  If THAT is really how it works then I can see it as a global only working on channels NOT enabled and NOT affecting channels that are enabled.  If my last statement is true, then I suggest the documentation be more clear on how this bit actually works and how to properly use it.  I made some assumptions and different test to come to the conclusion I stated above.

Joe

[davenadler]

Sounds like the electrical situation is OK and you've got decent PCB, signals, and power/ground with appropriate bypass caps everywhere. If it were me, next thing I'd do is:

1. Put the scope/logic analyzer on the SPI with a trigger on the 'block ready' signal. Let it run until there's an error and make sure not to again trigger; now the last xfer is on the scope. Is the data sent properly on the bus? Assumes you have a scope or logic analyzer up to the task (SPI decode etc) as I have here...
2. Send controlled test data and record what is missing and/or garbled. If the error is not random this will give a clue as to the problem source...

Hope that helps; let us know what you find,
Best Regards, Dave

[JHinkle]

Thanks for the reply Dave.

I had thought about trapping the SPI transfer with both scope and logic analyzer but concluded it would give me SPI signal data but that data would not help identify root cause -- here's why.

The captured scope and logic analyzer data would tell me if a SPI issue occurred (missing or garbled data).  But the issue is not SPI since the SPI captured all of the data.  The issue is that the DMA did not read the received SPI data before the next SPI data was fully clocked in (flag RFOF set).  All of the related SPI to DMA signals are inside the mcu - not exposed to any pins or signals.

As I see it ..

#1.  Upon clocking in the SPI data - did the SPI set the RFDF flag - if not why? -- this is one byte/transfer request out of 650 million bytes.  If this did not get set internally then NO DMA transfer would be requested.

#2.  If the SPI had set the RFDF flag - why did the DMA not proceed with a data transfer? 

I say that because I know 69 bytes were transmitted via SPI.  I know the DMA moved 68 bytes with the first byte being correct (that removes concern of start conditions). SPI shows RFOF set meaning that SPI did receive/clock in all 69 bytes - DMA did not transfer one of them - DMA moved 68 and is waiting for one more transfer request to finish the current TCD.

If you see it differently - please let me know.

Thanks again for your comments.

Joe

[davenadler]

Sorry, I missed the point that the missing byte is the last byte and sitting in the SPI but not transferred by DMA. Hmmmm... let me look into that...

[JHinkle]

No - I think we are still disconnected. 

I know the first byte of the SPI packet was transferred I do not know which of the remaining 68 were missed.  The SPI shows RFDF as cleared which would indicate the last byte was transferred but shows RDOF set meaning one of the middle 67 bytes were missed by the DMA.

That's my puzzle - why one out of 650 million bytes was missed by DMA?

Joe

[davenadler]

OK: RFDF cleared simply means there's nothing in the FIFO (ie, everything received without error was DMA'ed).

But RDOF means the SPI RX FIFO (only 1 deep on SPI2) overflowed. Freescale documentation says:
Indicates an overflow condition in the RX FIFO. The field is set when the RX FIFO and shift register are full and a transfer is initiated.
The bit remains set until it is cleared by writing a 1 to it.

RDOF could mean one of several things though...

1. The DMA didn't service the transfer fast enough. Could conceivably happen if you set DMA priority too low WRT other activities (but as you point out 8MHz isn't exactly blazing fast; only a byte per millisecond microsecond), or more likely if DMA was somehow disabled for a while??
2. Long shot, but possibly too many clocks, or CS de-asserted/re-asserted when unexpected?
3. DMA update wasn't properly sync'd at start of the current block. The DMA module has internal registers for memory locations you see and as I found they can get out of sync. How exactly do you update the buffer pointers and counts? If you do this on a DMA block-completion interrupt without disabling/re-enabling DMA things could get a bit woolly (hope I explained that OK).
4. The overflow bit stays set until cleared, so the byte lost could have been anywhere in the block.

Are you certain that the first byte of the block is received AOK? If there was a sync issue seems like the first byte would be the one to get lost.
Also, its curious that a TX underflow is reported (TFUF=1 above).
This is curious! Nothing in the errata about SPI, and DMA bugs don't seem relevant to this issue...
Grasping at straws here, sorry...

[JHinkle]

Dave:

Comments on your post.

#1.  You got timing wrong - 1 byte every microsec - not millisec.  Only channel active so no priority issue.

#2.  Two many clock or CS mishap would be identified in SPI status registers - SPI shows all 69 bytes successfully received.

#3.  DMA started outside of DMA IRQ.  After current data packet is processed the function (see code at top of post) is called setting buffer address and expected byte count.  After DMA is set to receive next packet, I toggle my Flow-Control IO pin which tells the other micro to start transmitting the next packet.

#4.  RFOF - as stated any of the 67 middle bytes between the first and last were missed by DMA.

I am positive the first byte is received.  The packet has header info which is correct.

TFUF means that a transmit could have occurred during a SPI transfer but no transmit data was supplied to the SPI xmit data register.  That is a valid flag because I don't transmit any data - only receive.

I was hoping NXP would identify a SPI or DMA errata on this subject since I would like to understand root-cause.

I have implemented a detection and recovery process that works well so I'm not dead in the water with an issue -- just an unanswered question.

Joe

[davenadler]

Right, 1 usec, plenty of time for the DMA (if not an ISR)...
"SPI shows all 69 bytes successfully received." Sorry, how?
Very curious...
Any chance you could test this with SPI0 (which actually has a functional FIFO)?

PS: You might find this bit of SPI tom-foolery amusing (you'll need to expand last entry to see the working answer):
20bit-spi-xfer

[mjbcswitzerland]

Joe

Is it possible that an overrun is signaled when a byte is lost?

Do you have multiple DMA channels in operation? If so, are you sure that there is not a situation where a higher priority DMA channel is performing burst mode transfers without allowing the one servicing SPI to do its work during this time?

For example, if you use a DMA channel for general purpose burst-mode memory to memory copy tasks (such as memcpy() or memset() based on DMA) is is important that the channel(s) used has lower priority that the channels servicing peripheral requests and that they are also set up to allow pre-emption by higher priority channels.

Regards

Mark

[JHinkle]

Thanks Mark.

Only one channel is enabled.

Joe

[davenadler]

Hi Joe - I've used K64F DMA on SPI extensively without dropping bytes. And it is AOK to run multiple DMA simultaneously despite strange replies above. First thing is: check really carefully that the electrical connection and grounding between the 2 MCU is perfect. Any problem with grounding or termination can lead to this kind of strange behavior, for example patch wires in air (rather than proper PCB connection)...

Hope that helps, Best Regards, Dave

PS: I also was surprised by the CX in the DMA_CR register affecting all channels. If you need to reset a specific channel, beware that any update is asynchronous with DMA and you may need to test/reset repeatedly; I needed this in related DMA code:

    // Amazingly, despite documentation, once every few minutes of runtime the major link enable below doesn't work.
    // Repeating it twice gets ten minutes, Yikes...
    while( ! (DMA0->TCD[1].CSR & DMA_CSR_MAJORELINK_MASK) ) {
        // Note: The user must clear the TCD.done bit before writing the TCD.major.e_link or TCD.e_sg bits.
        DMA0->CDNE = 1/*DMA channel#*/; // clear the DONE bit so we can update DMA channel 1 (linking after CNV)
        DMA0->TCD[1].CSR |= DMA_CSR_MAJORELINK_MASK; // set the MAJORELINK bit so CNV chains to ADC initiation
    };

PPS: When you're testing, it might be prudent to send known values, so you can find out which byte got lost, and/or whether any data got garbled... Is it always the same byte missing? Data corruption?

[JHinkle]

Mike:

By the way --- there is only one DMA channel active during this test so DMA abritration/priority should not come into play.  DMA missed a SPI byte and I can confirm it was not at the start of the transfer since first byte acquired is my header start byte and is correct.

What code/operations can cause a DMA cycle not to occur once a DMA transfer sequence has started since I'm assuming something caused the DMA not to respond to the SPI having data available before the next SPI data came in generating the overwrite flag.

Here are the SPI2 and DMA registers trapped at fault.

As you can see - SPI2 had RFOF flag set - but I don't see a DMA error.

SPI2 ..  ****************************************

SPI2_MCR 0x09010000
HALT 0
SMPL_PT 0
CLR_RXF 0
CLR_TXF 0
DIS_RXF 0
DIS_TXF 0
MDIS 0
DOZE 0
PCSIS 1
ROOE 1
PCSSE 0
MTFE 0
FRZ 1
DCONF 0
CONT_SCKE 0
MSTR 0
SPI2_TCR 0x10920000
SPI_TCNT 0x1092
SPI2_CTAR_SLAVE 0x3a000000
CPHA 1
CPOL 0
FMSZ 0x07
SPI2_CTAR0 0x3a000000
BR 0x0
DT 0x0
ASC 0x0
CSSCK 0x0
PBR 0
PDT 0
PASC 0
PCSSCK 0
LSBFE 0
CPHA 1
CPOL 0
FMSZ 0x7
DBR 0
SPI2_CTAR1 0x78000000
BR 0x0
DT 0x0
ASC 0x0
CSSCK 0x0
PBR 0
PDT 0
PASC 0
PCSSCK 0
LSBFE 0
CPHA 0
CPOL 0
FMSZ 0xf
DBR 0
SPI2_SR 0x8a080000
POPNXTPTR 0x0
RXCTR 0x0
TXNXTPTR 0x0
TXCTR 0x0
RFDF 0
RFOF 1    ******************************************* Note SPI error
TFFF 1
TFUF 1
EOQF 0
TXRXS 0
TCF 1
SPI2_RSER 0x00030000
RFDF_DIRS 1
RFDF_RE 1
RFOF_RE 0
TFFF_DIRS 0
TFFF_RE 0
TFUF_RE 0
EOQF_RE 0
TCF_RE 0
SPI2_PUSHR 0x00000000
TXDATA 0x0000
PCS 0
CTCNT 0
EOQ 0
CTAS 0
CONT 0
SPI2_PUSHR_SLAVE 0x00000000
TXDATA 0x00000000
SPI2_POPR 0x0000001a
RXDATA 0x0000001a
SPI2_TXFR0 0x00000000
TXDATA 0x0000
TXCMD_TXDATA 0x0000
SPI2_TXFR1
TXDATA
TXCMD_TXDATA
SPI2_TXFR2
TXDATA
TXCMD_TXDATA
SPI2_TXFR3
TXDATA
TXCMD_TXDATA
SPI2_RXFR0 0x0000001a
RXDATA 0x0000001a
SPI2_RXFR1
RXDATA
SPI2_RXFR2
RXDATA
SPI2_RXFR3
RXDATA

DMA   ************************************************
DMA_CR 0x00000000
EDBG 0
ERCA 0
HOE 0
HALT 0
CLM 0
EMLM 0
ECX 0
CX 0
DMA_ES 0x00000000
DBE 0
SBE 0
SGE 0
NCE 0
DOE 0
DAE 0
SOE 0
SAE 0
ERRCHN 0x0
CPE 0
ECX 0
VLD 0
DMA_ERQ 0x00004001
ERQ0 1
ERQ1 0
ERQ2 0
ERQ3 0
ERQ4 0
ERQ5 0
ERQ6 0
ERQ7 0
ERQ8 0
ERQ9 0
ERQ10 0
ERQ11 0
ERQ12 0
ERQ13 0
ERQ14 1
ERQ15 0
DMA_EEI 0x00000000
EEI0 0
EEI1 0
EEI2 0
EEI3 0
EEI4 0
EEI5 0
EEI6 0
EEI7 0
EEI8 0
EEI9 0
EEI10 0
EEI11 0
EEI12 0
EEI13 0
EEI14 0
EEI15 0
DMA_CEEI
CEEI
CAEE
NOP
DMA_SEEI
SEEI
SAEE
NOP
DMA_CERQ
CERQ
CAER
NOP
DMA_SERQ
SERQ
SAER
NOP
DMA_CDNE
CDNE
CADN
NOP
DMA_SSRT
SSRT
SAST
NOP
DMA_CERR
CERR
CAEI
NOP
DMA_CINT
CINT
CAIR
NOP
DMA_INT 0x00000000
INT0 0
INT1 0
INT2 0
INT3 0
INT4 0
INT5 0
INT6 0
INT7 0
INT8 0
INT9 0
INT10 0
INT11 0
INT12 0
INT13 0
INT14 0
INT15 0
DMA_ERR 0x00000000
ERR0 0
ERR1 0
ERR2 0
ERR3 0
ERR4 0
ERR5 0
ERR6 0
ERR7 0
ERR8 0
ERR9 0
ERR10 0
ERR11 0
ERR12 0
ERR13 0
ERR14 0
ERR15 0
DMA_HRS 0x00000000
HRS0 0
HRS1 0
HRS2 0
HRS3 0
HRS4 0
HRS5 0
HRS6 0
HRS7 0
HRS8 0
HRS9 0
HRS10 0
HRS11 0
HRS12 0
HRS13 0
HRS14 0
HRS15 0
DMA_DCHPRI3 0xc3
CHPRI 0x3
DPA 1
ECP 1
DMA_DCHPRI2 0xc2
CHPRI 0x2
DPA 1
ECP 1
DMA_DCHPRI1 0xc1
CHPRI 0x1
DPA 1
ECP 1
DMA_DCHPRI0 0x0e
CHPRI 0xe
DPA 0
ECP 0
DMA_DCHPRI7 0xc7
CHPRI 0x7
DPA 1
ECP 1
DMA_DCHPRI6 0xc6
CHPRI 0x6
DPA 1
ECP 1
DMA_DCHPRI5 0xc5
CHPRI 0x5
DPA 1
ECP 1
DMA_DCHPRI4 0xc4
CHPRI 0x4
DPA 1
ECP 1
DMA_DCHPRI11 0xcb
CHPRI 0xb
DPA 1
ECP 1
DMA_DCHPRI10 0xca
CHPRI 0xa
DPA 1
ECP 1
DMA_DCHPRI9 0xc9
CHPRI 0x9
DPA 1
ECP 1
DMA_DCHPRI8 0xc8
CHPRI 0x8
DPA 1
ECP 1
DMA_DCHPRI15 0xc0
CHPRI 0x0
DPA 1
ECP 1
DMA_DCHPRI14 0x0f
CHPRI 0xf
DPA 0
ECP 0
DMA_DCHPRI13 0x0c
CHPRI 0xc
DPA 0
ECP 0
DMA_DCHPRI12 0x0d
CHPRI 0xd
DPA 0
ECP 0
DMA_TCD0_SADDR 0x0008d7ea
SADDR 0x0008d7ea
DMA_TCD1_SADDR 0xc207ff66
SADDR 0xc207ff66
DMA_TCD2_SADDR 0x40804598
SADDR 0x40804598
DMA_TCD3_SADDR 0x66e7b351
SADDR 0x66e7b351
DMA_TCD4_SADDR 0x3e1b799a
SADDR 0x3e1b799a
DMA_TCD5_SADDR 0x16790c0f
SADDR 0x16790c0f
DMA_TCD6_SADDR 0x5b4d323d
SADDR 0x5b4d323d
DMA_TCD7_SADDR 0x9242459a
SADDR 0x9242459a
DMA_TCD8_SADDR 0xafb481c2
SADDR 0xafb481c2
DMA_TCD9_SADDR 0xaf9cc4e6
SADDR 0xaf9cc4e6
DMA_TCD10_SADDR 0xa63040dd
SADDR 0xa63040dd
DMA_TCD11_SADDR 0xc02777c1
SADDR 0xc02777c1
DMA_TCD12_SADDR 0x4324b813
SADDR 0x4324b813
DMA_TCD13_SADDR 0x1fff837c
SADDR 0x1fff837c
DMA_TCD14_SADDR 0x400ac038
SADDR 0x400ac038
DMA_TCD15_SADDR 0x543e0dac
SADDR 0x543e0dac
DMA_TCD0_SOFF 0x0002
SOFF 0x0002
DMA_TCD1_SOFF 0xba68
SOFF 0xba68
DMA_TCD2_SOFF 0x1b77
SOFF 0x1b77
DMA_TCD3_SOFF 0xed0c
SOFF 0xed0c
DMA_TCD4_SOFF 0xe7c7
SOFF 0xe7c7
DMA_TCD5_SOFF 0xce8b
SOFF 0xce8b
DMA_TCD6_SOFF 0x4af9
SOFF 0x4af9
DMA_TCD7_SOFF 0xec53
SOFF 0xec53
DMA_TCD8_SOFF 0x270b
SOFF 0x270b
DMA_TCD9_SOFF 0x20d1
SOFF 0x20d1
DMA_TCD10_SOFF 0x16fb
SOFF 0x16fb
DMA_TCD11_SOFF 0xb5f2
SOFF 0xb5f2
DMA_TCD12_SOFF 0x0001
SOFF 0x0001
DMA_TCD13_SOFF 0x0001
SOFF 0x0001
DMA_TCD14_SOFF 0x0000
SOFF 0x0000
DMA_TCD15_SOFF 0x45a8
SOFF 0x45a8
DMA_TCD1_ATTR 0x4442
DSIZE 0x2
DMOD 0x08
SSIZE 4
SMOD 8
DMA_TCD2_ATTR 0xcc41
DSIZE 0x1
DMOD 0x08
SSIZE 4
SMOD 25
DMA_TCD3_ATTR 0xb98b
DSIZE 0x3
DMOD 0x11
SSIZE 1
SMOD 23
DMA_TCD4_ATTR 0x10fa
DSIZE 0x2
DMOD 0x1f
SSIZE 0
SMOD 2
DMA_TCD5_ATTR 0x1c9e
DSIZE 0x6
DMOD 0x13
SSIZE 4
SMOD 3
DMA_TCD6_ATTR 0xf417
DSIZE 0x7
DMOD 0x02
SSIZE 4
SMOD 30
DMA_TCD7_ATTR 0x10f0
DSIZE 0x0
DMOD 0x1e
SSIZE 0
SMOD 2
DMA_TCD8_ATTR 0x1139
DSIZE 0x1
DMOD 0x07
SSIZE 1
SMOD 2
DMA_TCD9_ATTR 0xc3f2
DSIZE 0x2
DMOD 0x1e
SSIZE 3
SMOD 24
DMA_TCD10_ATTR 0xa1af
DSIZE 0x7
DMOD 0x15
SSIZE 1
SMOD 20
DMA_TCD11_ATTR 0x50fd
DSIZE 0x5
DMOD 0x1f
SSIZE 0
SMOD 10
DMA_TCD12_ATTR 0x0000
DSIZE 0x0
DMOD 0x00
SSIZE 0
SMOD 0
DMA_TCD13_ATTR 0x0000
DSIZE 0x0
DMOD 0x00
SSIZE 0
SMOD 0
DMA_TCD14_ATTR 0x0000
DSIZE 0x0
DMOD 0x00
SSIZE 0
SMOD 0
DMA_TCD15_ATTR 0x481d
DSIZE 0x5
DMOD 0x03
SSIZE 0
SMOD 9
DMA_TCD0_NBYTES_MLOFFYES 0x00000002
NBYTES 0x002
MLOFF 0x00000
DMLOE 0
SMLOE 0
DMA_TCD1_NBYTES_MLOFFYES 0xa48263de
NBYTES 0x3de
MLOFF 0x92098
DMLOE 0
SMLOE 1
DMA_TCD2_NBYTES_MLOFFYES 0x5314f91a
NBYTES 0x11a
MLOFF 0x4c53e
DMLOE 1
SMLOE 0
DMA_TCD3_NBYTES_MLOFFYES 0x9f133d4c
NBYTES 0x14c
MLOFF 0x7c4cf
DMLOE 0
SMLOE 1
DMA_TCD4_NBYTES_MLOFFYES 0x852a6dd4
NBYTES 0x1d4
MLOFF 0x14a9b
DMLOE 0
SMLOE 1
DMA_TCD5_NBYTES_MLOFFYES 0x59b408da
NBYTES 0x0da
MLOFF 0x66d02
DMLOE 1
SMLOE 0
DMA_TCD6_NBYTES_MLOFFYES 0x65730cb4
NBYTES 0x0b4
MLOFF 0x95cc3
DMLOE 1
SMLOE 0
DMA_TCD7_NBYTES_MLOFFYES 0x4ae54542
NBYTES 0x142
MLOFF 0x2b951
DMLOE 1
SMLOE 0
DMA_TCD8_NBYTES_MLOFFYES 0x17f320b8
NBYTES 0x0b8
MLOFF 0x5fcc8
DMLOE 0
SMLOE 0
DMA_TCD9_NBYTES_MLOFFYES 0xc3345b7b
NBYTES 0x37b
MLOFF 0x0cd16
DMLOE 1
SMLOE 1
DMA_TCD10_NBYTES_MLOFFYES 0xf85fdbe5
NBYTES 0x3e5
MLOFF 0xe17f6
DMLOE 1
SMLOE 1
DMA_TCD11_NBYTES_MLOFFYES 0xe1b14c14
NBYTES 0x014
MLOFF 0x86c53
DMLOE 1
SMLOE 1
DMA_TCD12_NBYTES_MLOFFYES 0x00000001
NBYTES 0x001
MLOFF 0x00000
DMLOE 0
SMLOE 0
DMA_TCD13_NBYTES_MLOFFYES 0x00000001
NBYTES 0x001
MLOFF 0x00000
DMLOE 0
SMLOE 0
DMA_TCD14_NBYTES_MLOFFYES 0x00000001
NBYTES 0x001
MLOFF 0x00000
DMLOE 0
SMLOE 0
DMA_TCD15_NBYTES_MLOFFYES 0x3c96eacf
NBYTES 0x2cf
MLOFF 0xf25ba
DMLOE 0
SMLOE 0
DMA_TCD0_NBYTES_MLOFFNO 0x00000002
NBYTES 0x00000002
DMLOE 0
SMLOE 0
DMA_TCD1_NBYTES_MLOFFNO 0xa48263de
NBYTES 0x248263de
DMLOE 0
SMLOE 1
DMA_TCD2_NBYTES_MLOFFNO 0x5314f91a
NBYTES 0x1314f91a
DMLOE 1
SMLOE 0
DMA_TCD3_NBYTES_MLOFFNO 0x9f133d4c
NBYTES 0x1f133d4c
DMLOE 0
SMLOE 1
DMA_TCD4_NBYTES_MLOFFNO 0x852a6dd4
NBYTES 0x052a6dd4
DMLOE 0
SMLOE 1
DMA_TCD5_NBYTES_MLOFFNO 0x59b408da
NBYTES 0x19b408da
DMLOE 1
SMLOE 0
DMA_TCD6_NBYTES_MLOFFNO 0x65730cb4
NBYTES 0x25730cb4
DMLOE 1
SMLOE 0
DMA_TCD7_NBYTES_MLOFFNO 0x4ae54542
NBYTES 0x0ae54542
DMLOE 1
SMLOE 0
DMA_TCD8_NBYTES_MLOFFNO 0x17f320b8
NBYTES 0x17f320b8
DMLOE 0
SMLOE 0
DMA_TCD9_NBYTES_MLOFFNO 0xc3345b7b
NBYTES 0x03345b7b
DMLOE 1
SMLOE 1
DMA_TCD10_NBYTES_MLOFFNO 0xf85fdbe5
NBYTES 0x385fdbe5
DMLOE 1
SMLOE 1
DMA_TCD11_NBYTES_MLOFFNO 0xe1b14c14
NBYTES 0x21b14c14
DMLOE 1
SMLOE 1
DMA_TCD12_NBYTES_MLOFFNO 0x00000001
NBYTES 0x00000001
DMLOE 0
SMLOE 0
DMA_TCD13_NBYTES_MLOFFNO 0x00000001
NBYTES 0x00000001
DMLOE 0
SMLOE 0
DMA_TCD14_NBYTES_MLOFFNO 0x00000001
NBYTES 0x00000001
DMLOE 0
SMLOE 0
DMA_TCD15_NBYTES_MLOFFNO 0x3c96eacf
NBYTES 0x3c96eacf
DMLOE 0
SMLOE 0
DMA_TCD0_NBYTES_MLNO 0x00000002
NBYTES 0x00000002
DMA_TCD1_NBYTES_MLNO 0xa48263de
NBYTES 0xa48263de
DMA_TCD2_NBYTES_MLNO 0x5314f91a
NBYTES 0x5314f91a
DMA_TCD3_NBYTES_MLNO 0x9f133d4c
NBYTES 0x9f133d4c
DMA_TCD4_NBYTES_MLNO 0x852a6dd4
NBYTES 0x852a6dd4
DMA_TCD5_NBYTES_MLNO 0x59b408da
NBYTES 0x59b408da
DMA_TCD6_NBYTES_MLNO 0x65730cb4
NBYTES 0x65730cb4
DMA_TCD7_NBYTES_MLNO 0x4ae54542
NBYTES 0x4ae54542
DMA_TCD8_NBYTES_MLNO 0x17f320b8
NBYTES 0x17f320b8
DMA_TCD9_NBYTES_MLNO 0xc3345b7b
NBYTES 0xc3345b7b
DMA_TCD10_NBYTES_MLNO 0xf85fdbe5
NBYTES 0xf85fdbe5
DMA_TCD11_NBYTES_MLNO 0xe1b14c14
NBYTES 0xe1b14c14
DMA_TCD12_NBYTES_MLNO 0x00000001
NBYTES 0x00000001
DMA_TCD13_NBYTES_MLNO 0x00000001
NBYTES 0x00000001
DMA_TCD14_NBYTES_MLNO 0x00000001
NBYTES 0x00000001
DMA_TCD15_NBYTES_MLNO 0x3c96eacf
NBYTES 0x3c96eacf
DMA_TCD0_SLAST 0x00000000
SLAST 0x00000000
DMA_TCD1_SLAST 0xd56d50df
SLAST 0xd56d50df
DMA_TCD2_SLAST 0xc58ffb9e
SLAST 0xc58ffb9e
DMA_TCD3_SLAST 0xac0c668b
SLAST 0xac0c668b
DMA_TCD4_SLAST 0x6d52a635
SLAST 0x6d52a635
DMA_TCD5_SLAST 0x2d0f8bcf
SLAST 0x2d0f8bcf
DMA_TCD6_SLAST 0xa7b2e9cb
SLAST 0xa7b2e9cb
DMA_TCD7_SLAST 0x959d85a9
SLAST 0x959d85a9
DMA_TCD8_SLAST 0x3cd71f9e
SLAST 0x3cd71f9e
DMA_TCD9_SLAST 0x59d9239a
SLAST 0x59d9239a
DMA_TCD10_SLAST 0x325b9323
SLAST 0x325b9323
DMA_TCD11_SLAST 0x845f27e0
SLAST 0x845f27e0
DMA_TCD12_SLAST 0x00000000
SLAST 0x00000000
DMA_TCD13_SLAST 0x00000000
SLAST 0x00000000
DMA_TCD14_SLAST 0x00000000
SLAST 0x00000000
DMA_TCD15_SLAST 0x3aaab7e4
SLAST 0x3aaab7e4
DMA_TCD0_DADDR 0x4002f020
DADDR 0x4002f020
DMA_TCD1_DADDR 0x8e8da340
DADDR 0x8e8da340
DMA_TCD2_DADDR 0x70ba8037
DADDR 0x70ba8037
DMA_TCD3_DADDR 0x24a4c678
DADDR 0x24a4c678
DMA_TCD4_DADDR 0xd1cd113e
DADDR 0xd1cd113e
DMA_TCD5_DADDR 0xd2a20d18
DADDR 0xd2a20d18
DMA_TCD6_DADDR 0xf1809c39
DADDR 0xf1809c39
DMA_TCD7_DADDR 0x5e102cd7
DADDR 0x5e102cd7
DMA_TCD8_DADDR 0x438da19f
DADDR 0x438da19f
DMA_TCD9_DADDR 0x51020001
DADDR 0x51020001
DMA_TCD10_DADDR 0x640a9dca
DADDR 0x640a9dca
DMA_TCD11_DADDR 0x75404c13
DADDR 0x75404c13
DMA_TCD12_DADDR 0x4002d034
DADDR 0x4002d034
DMA_TCD13_DADDR 0x4002c034
DADDR 0x4002c034
DMA_TCD14_DADDR 0x20001380
DADDR 0x20001380
DMA_TCD15_DADDR 0x622590b5
DADDR 0x622590b5
DMA_TCD0_DOFF 0x0000
DOFF 0x0000
DMA_TCD1_DOFF 0xc260
DOFF 0xc260
DMA_TCD2_DOFF 0x2cea
DOFF 0x2cea
DMA_TCD3_DOFF 0x3829
DOFF 0x3829
DMA_TCD4_DOFF 0x1389
DOFF 0x1389
DMA_TCD5_DOFF 0x32e5
DOFF 0x32e5
DMA_TCD6_DOFF 0x1d15
DOFF 0x1d15
DMA_TCD7_DOFF 0x6a3d
DOFF 0x6a3d
DMA_TCD8_DOFF 0x6225
DOFF 0x6225
DMA_TCD9_DOFF 0x7d3b
DOFF 0x7d3b
DMA_TCD10_DOFF 0x6d00
DOFF 0x6d00
DMA_TCD11_DOFF 0x026b
DOFF 0x026b
DMA_TCD12_DOFF 0x0000
DOFF 0x0000
DMA_TCD13_DOFF 0x0000
DOFF 0x0000
DMA_TCD14_DOFF 0x0001
DOFF 0x0001
DMA_TCD15_DOFF 0x007d
DOFF 0x007d
DMA_TCD0_CITER_ELINKYES 0x01e9
CITER 0x1e9
LINKCH 0x0
ELINK 0
DMA_TCD1_CITER_ELINKYES 0x0f1b
CITER 0x11b
LINKCH 0x7
ELINK 0
DMA_TCD2_CITER_ELINKYES 0x0cd5
CITER 0x0d5
LINKCH 0x6
ELINK 0
DMA_TCD3_CITER_ELINKYES 0xb256
CITER 0x056
LINKCH 0x9
ELINK 1
DMA_TCD4_CITER_ELINKYES 0x6253
CITER 0x053
LINKCH 0x1
ELINK 0
DMA_TCD5_CITER_ELINKYES 0xedf9
CITER 0x1f9
LINKCH 0x6
ELINK 1
DMA_TCD6_CITER_ELINKYES 0xc203
CITER 0x003
LINKCH 0x1
ELINK 1
DMA_TCD7_CITER_ELINKYES 0x6688
CITER 0x088
LINKCH 0x3
ELINK 0
DMA_TCD8_CITER_ELINKYES 0x42db
CITER 0x0db
LINKCH 0x1
ELINK 0
DMA_TCD9_CITER_ELINKYES 0x5963
CITER 0x163
LINKCH 0xc
ELINK 0
DMA_TCD10_CITER_ELINKYES 0xe4da
CITER 0x0da
LINKCH 0x2
ELINK 1
DMA_TCD11_CITER_ELINKYES 0x220d
CITER 0x00d
LINKCH 0x1
ELINK 0
DMA_TCD12_CITER_ELINKYES 0xe242
CITER 0x042
LINKCH 0x1
ELINK 1
DMA_TCD13_CITER_ELINKYES 0x0014
CITER 0x014
LINKCH 0x0
ELINK 0
DMA_TCD14_CITER_ELINKYES 0x0001
CITER 0x001
LINKCH 0x0
ELINK 0
DMA_TCD15_CITER_ELINKYES 0x2404
CITER 0x004
LINKCH 0x2
ELINK 0
DMA_TCD0_CITER_ELINKNO 0x01e9
CITER 0x01e9
ELINK 0
DMA_TCD1_CITER_ELINKNO 0x0f1b
CITER 0x0f1b
ELINK 0
DMA_TCD2_CITER_ELINKNO 0x0cd5
CITER 0x0cd5
ELINK 0
DMA_TCD3_CITER_ELINKNO 0xb256
CITER 0x3256
ELINK 1
DMA_TCD4_CITER_ELINKNO 0x6253
CITER 0x6253
ELINK 0
DMA_TCD5_CITER_ELINKNO 0xedf9
CITER 0x6df9
ELINK 1
DMA_TCD6_CITER_ELINKNO 0xc203
CITER 0x4203
ELINK 1
DMA_TCD7_CITER_ELINKNO 0x6688
CITER 0x6688
ELINK 0
DMA_TCD8_CITER_ELINKNO 0x42db
CITER 0x42db
ELINK 0
DMA_TCD9_CITER_ELINKNO 0x5963
CITER 0x5963
ELINK 0
DMA_TCD10_CITER_ELINKNO 0xe4da
CITER 0x64da
ELINK 1
DMA_TCD11_CITER_ELINKNO 0x220d
CITER 0x220d
ELINK 0
DMA_TCD12_CITER_ELINKNO 0xe242
CITER 0x6242
ELINK 1
DMA_TCD13_CITER_ELINKNO 0x0014
CITER 0x0014
ELINK 0
DMA_TCD14_CITER_ELINKNO 0x0001       *************************** 1 byte missed in transfer
CITER 0x0001
ELINK 0
DMA_TCD15_CITER_ELINKNO 0x2404
CITER 0x2404
ELINK 0
DMA_TCD0_DLASTSGA 0x00000000
DLASTSGA 0x00000000
DMA_TCD1_DLASTSGA 0xc331765d
DLASTSGA 0xc331765d
DMA_TCD2_DLASTSGA 0x808ba709
DLASTSGA 0x808ba709
DMA_TCD3_DLASTSGA 0x45d76024
DLASTSGA 0x45d76024
DMA_TCD4_DLASTSGA 0xe44ee69d
DLASTSGA 0xe44ee69d
DMA_TCD5_DLASTSGA 0x1bc8669d
DLASTSGA 0x1bc8669d
DMA_TCD6_DLASTSGA 0x81d8c40d
DLASTSGA 0x81d8c40d
DMA_TCD7_DLASTSGA 0x9dc6ad05
DLASTSGA 0x9dc6ad05
DMA_TCD8_DLASTSGA 0xa2a9fe41
DLASTSGA 0xa2a9fe41
DMA_TCD9_DLASTSGA 0xc1fab35b
DLASTSGA 0xc1fab35b
DMA_TCD10_DLASTSGA 0x63d5982e
DLASTSGA 0x63d5982e
DMA_TCD11_DLASTSGA 0x5a1c65fb
DLASTSGA 0x5a1c65fb
DMA_TCD12_DLASTSGA 0x00000000
DLASTSGA 0x00000000
DMA_TCD13_DLASTSGA 0x00000000
DLASTSGA 0x00000000
DMA_TCD14_DLASTSGA 0x00000000
DLASTSGA 0x00000000
DMA_TCD15_DLASTSGA 0x809d462c
DLASTSGA 0x809d462c
DMA_TCD0_CSR 0x0002
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x0
BWC 0
DMA_TCD1_CSR 0xe306
START 0
INTMAJOR 1
INTHALF 1
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x3
BWC 3
DMA_TCD2_CSR 0xc428
START 0
INTMAJOR 0
INTHALF 0
DREQ 1
ESG 0
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0x4
BWC 3
DMA_TCD3_CSR 0x1a3a
START 0
INTMAJOR 1
INTHALF 0
DREQ 1
ESG 1
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0xa
BWC 0
DMA_TCD4_CSR 0x223e
START 0
INTMAJOR 1
INTHALF 1
DREQ 1
ESG 1
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0x2
BWC 0
DMA_TCD5_CSR 0xf632
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 1
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0x6
BWC 3
DMA_TCD6_CSR 0xed04
START 0
INTMAJOR 0
INTHALF 1
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0xd
BWC 3
DMA_TCD7_CSR 0xc032
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 1
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0x0
BWC 3
DMA_TCD8_CSR 0x3a32
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 1
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0xa
BWC 0
DMA_TCD9_CSR 0xe50e
START 0
INTMAJOR 1
INTHALF 1
DREQ 1
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x5
BWC 3
DMA_TCD10_CSR 0x6f02
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0xf
BWC 1
DMA_TCD11_CSR 0xef2e
START 0
INTMAJOR 1
INTHALF 1
DREQ 1
ESG 0
MAJORELINK 1
ACTIVE 0
DONE 0
MAJORLINKCH 0xf
BWC 3
DMA_TCD12_CSR 0x0002
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x0
BWC 0
DMA_TCD13_CSR 0x0002
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x0
BWC 0
DMA_TCD14_CSR 0x0002
START 0
INTMAJOR 1
INTHALF 0
DREQ 0
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x0
BWC 0
DMA_TCD15_CSR 0xe90c
START 0
INTMAJOR 0
INTHALF 1
DREQ 1
ESG 0
MAJORELINK 0
ACTIVE 0
DONE 0
MAJORLINKCH 0x9
BWC 3
DMA_TCD0_BITER_ELINKYES 0x0800
BITER 0x000
LINKCH 0x4
ELINK 0
DMA_TCD1_BITER_ELINKYES 0xa673
BITER 0x073
LINKCH 0x3
ELINK 1
DMA_TCD2_BITER_ELINKYES 0x5573
BITER 0x173
LINKCH 0xa
ELINK 0
DMA_TCD3_BITER_ELINKYES 0x1339
BITER 0x139
LINKCH 0x9
ELINK 0
DMA_TCD4_BITER_ELINKYES 0x41d6
BITER 0x1d6
LINKCH 0x0
ELINK 0
DMA_TCD5_BITER_ELINKYES 0x853b
BITER 0x13b
LINKCH 0x2
ELINK 1
DMA_TCD6_BITER_ELINKYES 0x1ec2
BITER 0x0c2
LINKCH 0xf
ELINK 0
DMA_TCD7_BITER_ELINKYES 0xf269
BITER 0x069
LINKCH 0x9
ELINK 1
DMA_TCD8_BITER_ELINKYES 0x1a88
BITER 0x088
LINKCH 0xd
ELINK 0
DMA_TCD9_BITER_ELINKYES 0xbf8a
BITER 0x18a
LINKCH 0xf
ELINK 1
DMA_TCD10_BITER_ELINKYES 0x781e
BITER 0x01e
LINKCH 0xc
ELINK 0
DMA_TCD11_BITER_ELINKYES 0xb28d
BITER 0x08d
LINKCH 0x9
ELINK 1
DMA_TCD12_BITER_ELINKYES 0x4f8b
BITER 0x18b
LINKCH 0x7
ELINK 0
DMA_TCD13_BITER_ELINKYES 0x0018
BITER 0x018
LINKCH 0x0
ELINK 0
DMA_TCD14_BITER_ELINKYES 0x0045
BITER 0x045
LINKCH 0x0
ELINK 0
DMA_TCD15_BITER_ELINKYES 0xdab0
BITER 0x0b0
LINKCH 0xd
ELINK 1
DMA_TCD1_BITER_ELINKNO 0xa673
BITER 0x2673
ELINK 1
DMA_TCD2_BITER_ELINKNO 0x5573
BITER 0x5573
ELINK 0
DMA_TCD3_BITER_ELINKNO 0x1339
BITER 0x1339
ELINK 0
DMA_TCD4_BITER_ELINKNO 0x41d6
BITER 0x41d6
ELINK 0
DMA_TCD5_BITER_ELINKNO 0x853b
BITER 0x053b
ELINK 1
DMA_TCD6_BITER_ELINKNO 0x1ec2
BITER 0x1ec2
ELINK 0
DMA_TCD7_BITER_ELINKNO 0xf269
BITER 0x7269
ELINK 1
DMA_TCD8_BITER_ELINKNO 0x1a88
BITER 0x1a88
ELINK 0
DMA_TCD9_BITER_ELINKNO 0xbf8a
BITER 0x3f8a
ELINK 1
DMA_TCD10_BITER_ELINKNO 0x781e
BITER 0x781e
ELINK 0
DMA_TCD11_BITER_ELINKNO 0xb28d
BITER 0x328d
ELINK 1
DMA_TCD12_BITER_ELINKNO 0x4f8b
BITER 0x4f8b
ELINK 0
DMA_TCD13_BITER_ELINKNO 0x0018
BITER 0x0018
ELINK 0
DMA_TCD14_BITER_ELINKNO 0x0045
BITER 0x0045
ELINK 0
DMA_TCD15_BITER_ELINKNO 0xdab0
BITER 0x5ab0
ELINK 1
DMA_TCD0_BITER_ELINKNO
BITER
ELINK
DMA_TCD0_ATTR
DSIZE
DMOD
SSIZE
SMOD

[Hui_Ma]

Hi Joe,

I checked the DMA_TCD14_CSR register value is   0x2.

Could you try to enable [DREQ] bit also? Set DMA_TCD14_CSR register value to 0xA.

Please try if it could fix the issue.

Wish it helps.

Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JHinkle]

Mike:

I question your direction on setting the DREQ bit.  My under standing is that if that bit is set, then the channel becomes inactive at the completion of the defined TCD process.  That would require me to enable the channel every time I wanted to start a new TCD.  Today, I leave the channel active and just write a new destination and new CITER/BITER values.  I know the channel is "inactive" from a SPI hardware perspective because I have handshaking for flow control.

What are your thoughts as to why setting this bit might be helpful?  Is it because the current SDK sets that bit which I can see why since the SDK is written for general use and is not always written for performance.

I really appreciate your helping on this Mike - Thanks again.

Joe 

[Hui_Ma]

Hi Joe,

Sorry for the later reply.

In fact, after the current TCD process completed, it still has code to refresh new TCD setting for the coming transfer.

The DREQ bit could avoid DMA engine incorrect operation during new TCD load phase with coming DMA trigger.

That could happen at the beginning of DMA transfer.

When do you application code to refresh the new TCD setting?

I know your application with issue at receive the last byte.

While, please check if there exists possible that new TCD setting loaded during the DMA engine still working.

best regards,

Mike

[JHinkle]

Mike:

Thanks for your reply.

The new DMA TCD setting are loaded after DMA IRQ completion is performed and channel is no longer active.  The DMA IRQ gives a mutex which eanble thread to run - process acquired SPI data, perform Handshake flow control, then sets new DMA settings.

New DMA trigger can not occur until after handshake flow control - that is what tells the master that every thing is in place for the next SPI packet to be sent.

Your concern never happens.

Best regards

Joe

[Hui_Ma]

Thank you, Joe.

Could you share your DMA IRQ code?

If you could change the processing with perform Handshake flow control, then sets new DMA settings?

Please try to sets new DMA TCD setting at first, then perform Handshake flow control.

Please let us know if there still with the issue.

BTW: Happy New Year 2019!

best regards,

Mike

[JHinkle]

Mike:

Thanks for your reply.

I will attempt to trap the error (it can take up to 4 hours for it to occur).  I always look at the registers to see if I can identify any error - which I did not -- I will capture and have you look.

Thanks for the table.  I was looking all over the "SPI" chapter for the FIFO size for SPI2.  I thought they were different but the SPI chapter said the FIFO was 4 deep (I work with multiple Kinetis parts and thought the K64 might actuall be 4 for all SPIs).  Lesson learned -- always check chapter 3 along with specific function chapter.

Your answer 3 above disturbs me as it violates my understanding of DMA:

Mike wrote:    3> There with one DMA engine, only one DMA channel can do the transfer at same time.

I understand that only one DMA transfer can take place at a time - that's why there are priorities.  If two DMA channels are active - and each channels has a different time between transfers (say a slow baud UART and a fast SPI - and SPI has higher priority) - I thought that DMA could/would make a UART transfer in between a SPI transfer as long as a SPI transfer was not needed at THAT time slot -- thereby handling both channels at the same time.

Does your #3 statement above means that once a DMA channel transfer begins - that channel must complete before another channel can start?  Can you point out a chapter/page in the K64 manual that describes that behavior?

22.4.1 eDMA basic data flow - shows the flow thru the various stages of DMA execution.  It states:

In the next cycle, the channel
arbitration performs, using the fixed-priority or round-robin algorithm. After arbitration is
complete, the activated channel number is sent through the address path and converted
into the required address to access the local memory for TCDn.

I was understanding this to state that there can be multiple active channels making transfers intertwined with each other with arbitration based on priority when both channels want data moved at the same time.  That is why I asked about the CX bit since multiple channels to me could be active at the same time. ... Example  SPI byte, SPI byte,  UART byte, SPI byte, SPI byte ...

Thanks.

Joe

[Hui_Ma]

Hi Joe,

About eDMA handling multiple transfer requests, please check AN4765 chapter 3.1 for detailed info.

Although the AN4765 for MPC57xx eDMA module, which also be suitable for K64 eDMA module.

Wish it helps.

Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[JHinkle]

Thanks Mike for link to  AN4765 .

You blew my understanding out the window.  IMO - DMA kind of sucks now since I can't use it to process two "incoming"  data streams that may be active at the same time.  Looks like interrupt processing may still be the best practice if the data rate allows for it -- at least then I can acquire multiple streams at the same time.

The explanation in  AN4765should be  included as a link in most the the users manuals that have DMA capabilities.

Thanks again for that clarification - luckily I never had two streams being transferred at the same time -- but now I can properly use it in the future.

Joe