This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

6657 EDMA transfer problem

Hi,

I'm trying to activate the EDMA.

After setting and triggering the channel I wait on the pending interrupt register for a completion indication.

I get the interrupt but no transfer happened (destination buffer remained empty)?

Is there any other status indication that can say what went wrong?

Thanks,

Ilan.

  • Hi,

    Thanks for your post.

    How do you ensure the DMA transfer completion interrupt? Is the interrupt pending register (IPR / IPRH) relevant bit position appropriate to the DMA event been set on transfer completion?

    Few suggestions:

    Please, ensure first whether TCINTEN bit is enabled in channel OPT and only then, the interrupt pending register (IPR / IPRH) relevant bit position appropriate to the DMA event would be set on transfer completion

    Also, ensure the TCCMODE bit in OPT which would indicate normal or early completion of data transfer and again, I would suggest you to validate the received TCC code in OPT first on the triggered DMA channel and accordingly, the corresponding bit position in IPR/IPRH would be set which is directly the TCC value and thereafter, the corresponding IER[TCC] / IERH [TCC] bit would be set to generate a EDMA completion interrupt to the DSP. By the way, the same 6-bit TCC would be posted by the TC to the CC after it receives the transfer completion signal from the destination peripheral in normal completion mode. Have you checked this?

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Hi Sivaraj K,

    Thank you for your answer.

    The OPT is 0x80100004, so TCINTEN is set to '1' and Mode is '0' (Normal)

    After triggering the EDMA the OPT changed to 0x80101004 (means TCC = 0b001000)

    As I said before I get the IPR after the EDMA was triggered,, but no transfer is taking place
    between source address (0x00880000) and destination address (0x00880800).

    Are the above settings correct and sufficient for the requested transfer?

    And I'm asking again, can I see in any registers the status of the operation?

    Thanks,
    Ilan.
  • Hi,

    Thanks for your update.

    Starting from CC, please ensure if any outstanding completion requests submission to the TC are pending and check the status on the same through "COMPACTV" bit field of CCSTAT register (see Table 4.25 below) and also check the transfer request status through "TRACTV" bit field on the same CCSTAT

    http://www.ti.com/lit/ug/sprugs5b/sprugs5b.pdf

    Next coming to TC, check the destination FIFO status and source controller of EDMA3TC through bit fields "DSTACTV" and "SRCACTV" of TCSTAT register (see Table 4-68 on the above guide). Kindly check how many TR's are residing in destination FIFO and primarily these bit fields are used for advanced debugging.

    In addition to above, you could also set enable bits in ERREN (see section 4.3.4.2) and correspondingly ERRSTAT (see section 4.3.4.1) register would assert any EDMA3TC interrupt in case of any error events. This is to confirm that, no bus error or TR error or MMR address error occurs on EDMA3TC

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Hi,

    The CCSTAT register = 0x0, so COMPACTV and TRACTV are '0'.
    The TCSTAT register = 0x100, so DSTACT and SRCACTV are '0'

    As I understand it, these statuses say that there are no pending transfers, am I right?

    Is there any status register that say how many transfers occured, if any?

    I'm using the Ping-Pong example, so in the parameters area there are two sets of parameters.
    'Ping' parameters and 'Pong' parameters.
    I saw a starnge phenomena, after 'Ping' is triggered, it seems that the parameters of 'Pong'
    are set into 'ping' parameters area (??...)
    Can it expalin anything?

    Thanks again,

    Ilan.
  • Hi,

    Thanks for your update.

    I don't think, there are status registers to check for the no. of transfers happened in the TC, hopefully NO to this.

    As per my understanding, there is only way which would let us know is through receiving the expected EDMA3 completion interrupt to CPU on transfer completion where the appropriate interrupts are being setup in the device interrupt controller through enabling in the IER/IERH by writing into IESR/IESRH.

    Do you see any EDMA3TC interrupt error being asserted in ERRSTAT register of TC in case of any error events?

    You could also try checking the TCCERR bit field status of CCERR register ( see Table 4-17 on sprugs5b) which would indicate the max. reach limit of allowed total number of TCCs and check if any TCCs outstanding.

    I wonder, after the TCC is generated by TC which triggers the corresponding bit position in IPR/IPRH followed by setting  IER[TCC] / IERH [TCC] bit would generate EDMA3 completion interrupt to cpu, howcome the transfer wouldn't have happened? It looks strange to me. May be, you could try writing it to EVAL bit in IEVAL register (see Table 4-58 on sprugs5b) which would pulse the EDMA3CC global completion interrupt and this would ensure that the EDMA completion interrupts is not being missed by the cpu.

    Do you see nonzero status/error code detected on the read status or write status bus on the "STAT" bit field of ERRDET register (see Table 4-72 on sprugs5b) which would let you know the read/write transaction error status on the EDMA3TC which may block the DMA data transfer? Kindly check this?

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Hi,

    I checked the Channel Configuration:
    CCERR (0x2740318) = 0x0
    IEVAL (0x2742078) = 0x0

    The Transfer Controller 3 showed the following:
    ERRSTAT (0x27A80120) = 0x9 =====> MMRAERR & BUSERR
    ERRDET (0x27A8012C) = 0x00010001 ==-===> TCINTEN + STAT (Read Error)

    These registers were set after calling the CSL_edma3HwChannelControl()
    with the command CSL_EDMA3_CMD_CHANNEL_SET to trigger the channel.

    As I understand this function sets the ESR, what can go wrong there?

    Thanks,
    Ilan.
  • Hi,

    It seems that the ERRSTAT register (0x27A80120) holds always the MMRAERR (bit 3) set.

    After triggering the transfer, the ERRSTAT register (0x27A80120) = 0x9 ===> MMRAERR & BUSERR.

    ERRDET (0x27A8012C) = 0x00010001 ==-===> TCINTEN + STAT (Read Error)

    Activating setting 0x9 on ERRCLR (0x027A8128) clears ERRDET but leaves ERRSTAT = 0x8

    The PaRam data I use is as follows:

    OPT               = 0x80100004

    SRC Address       = 0x00880000

    BCNT + ACNT       = 0x04000001

    DST Address       = 0x00880800

    DSTBIDX & SRCBIDX = 0x00010001

    BCNTRLD & Link    = 0x0000FFFF

    DSTCIDX & SRCCIDX = 0x00010000

    CCNT              = 0x00000001

    After setting the ESR to trigger the transfer,I got the following data set in the registers:

    IPR      = 0x00000001

    TCSTAT   = 0x00000900

    ERRSTAT  = 0x00000009

    ERRDET   = 0x00100001

    SAOPT     = 0x00100000

    SASRC     = 0x008803c0

    SACNT     = 0x00000400

    SABIDX    = 0x00010001

    SAMPPRXY  = 0x00000100

    SACNTRLD  = 0x00000400

    SASRCBREF = 0x00880000

    While I made several iterations , I saw that on each iteration some registers that were set

    in the previous iteration were modified in the current one (set in RED)

    iteration #1:

    DFOPT0   = 0x00100000   DFSRC0     = 0x00000000   DFCNT0 = 0x00000000 DFDST0 = 0x00880BC0

    DFBIDIX0 = 0x00010001   DFMPPPRXY0 = 0x00000100   0x27A8318 = 0x00000000

    iteration #2:

    DFOPT0   = 0x00100000   DFSRC0     = 0x00000000  DFCNT0 = 0x00000400  DFDST0 = 0x00880800

    DFBIDIX0 = 0x00010001   DFMPPPRXY0 = 0x00000100       0x27A8318 = 0x00000001

    DFOPT1   = 0x00100000   DFSRC1     = 0x00000000  DFCNT1 = 0x00000000  DFDST1 = 0x00880BC0

    DFBIDIX1 = 0x00010001   DFMPPPRXY1 = 0x00000100         0x27A8358 = 0x00000000

    iteration #3:

    DFOPT0   = 0x00100000   DFSRC0      = 0x00000000  DFCNT0 = 0x00000400  DFDST0 = 0x00880800

    DFBIDIX0 = 0x00010001   DFMPPPRXY0  = 0x00000100     0x27A8318 = 0x00000001

    DFOPT1   = 0x00100000   DFSRC1      = 0x00000000  DFCNT1 = 0x00000400  DFDST1 = 0x00880800

    DFBIDIX1 = 0x00010001   DFMPPPRXY1  = 0x00000100      0x27A8358 = 0x00000001

    DFOPT2   = 0x00100000   DFSRC2      = 0x00000000  DFCNT2 = 0x00000000  DFDST2 = 0x00880BC0

    DFBIDIX2 = 0x00010001   DFMPPPRXY2  = 0x00000100        0x27A8398 = 0x00000000

    iteration #4:

    DFOPT0   = 0x00100000   DFSRC0      = 0x00000000  DFCNT0 = 0x00000400  DFDST0 = 0x00880800

    DFBIDIX0 = 0x00010001   DFMPPPRXY0  = 0x00000100       0x27A8318 = 0x00000001

    DFOPT1   = 0x00100000   DFSRC1      = 0x00000000  DFCNT1 = 0x00000400  DFDST1 = 0x00880800

    DFBIDIX1 = 0x00010001   DFMPPPRXY1  = 0x00000100        0x27A8358 = 0x00000001

    DFOPT2   = 0x00100000   DFSRC2      = 0x00000000  DFCNT2 = 0x00000400  DFDST2 = 0x00880800

    DFBIDIX2 = 0x00010001   DFMPPPRXY2  = 0x00000100        0x27A8398 = 0x00000001

    DFOPT3   = 0x00100000   DFSRC3      = 0x00000000  DFCNT3 = 0x00000000  DFDST3 = 0x00880BC0

    DFBIDIX3 = 0x00010001   DFMPPPRXY3  = 0x00000100        0x27A83D8 = 0x00000000

    Can you please explain me the meaning of DFDSTx  and how can it once  hold  a starnge  dst address (0x880BC0)

    and in the  following iteration it holds the exact start  destination address 

    Could some of the above tell why on each triggering the transfer I got the IPR set while no transfer is taking place?

    Thanks in advance.

    Ilan.

  • Hi,

    Thanks for your update.

    DFDSTx is just the destination address for the destination FIFO register set and to my opinion, the possible destination address it could hold and the final value should be the address of the last write command issued when the transfer request is complete.

    If the TCINTEN bit in the channel option parameter (OPT) is set in the PaRAM entry associated with the DMA channel, then the EDMA3TC returns a completion code on transfer. When an interrupt transfer completion code with TCC = n is detected by the EDMA3CC, then the corresponding bit would be set automatically in the interrupt pending register (IPR. IPRH) which are read only.

    Note that once a bit is being set in the interrupt pending registers, it would remains set and it is your responsibility to clear these bits. The bits set in IPR/IPRH can be cleared by writing a 1 to the corresponding bits in the interrupt clear registers (ICR/ICRH).

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Hi,

    Thanks again for the prompt answer.

    So, I didn't quite understand if my PaRam setting is OK, and specially if the OPT setting is OK.

    In order to initiate a simple block transfer from SRC address 0x880000 to DST addres 0x880800

    in a size of ACNT = 1 and BCNT = 0x400 is the following OPT correct:

    PRIV           =  1    

    PRIVID       = 0

    ITCCHEN   = 0          (Intermiate transfer complete chaining is disabled)

    TCCHEN    = 0          (Transfer complete chaining is disabled)

    ITCINTEN = 0        (Intermiate transfer complete chaining interrupt is disabled)

    TCINTEN   = 1         (Transfer complete chaining interrupt is enabled)

    TCC             = 0          ( Is it correct, or what setting need to be used?)

    TCCMOD  = 0          (Normal Completion)

    FWID         = 0                  (FIFO Width 8 bit)

    STATIC     = 0              

    SYNCDIM = 1          (AB- synchronized)

    DAM           = 0         (Increment)

    SAM            = 0           (Increment)

    and are the other PaRam data as mentioned in my previous post set OK?

    Thanks,

    Ilan.

  • Hi,

    Thanks for your update.

    As far as i believe, the TCC value is directly mapped to DMA channel no. triggered by the peripheral DMA Tx/Rx/ events.

    To clarify you that any TCC value cannot be set in the PaRAM and the fact is that the 6-bit TCC would be posted by the TC to the CC after it receives the transfer completion signal from the destination peripheral in normal completion mode. This 6-bit code sets the relevant bit in the interrupt pending register (IPR [TCC] / IPRH [TCC]) for interrupt triggered.

    I would suggest you to validate the received TCC code in OPT first and accordingly, the bit position in IPR/IPRH would be set which is directly the TCC value and thereafter, the corresponding IER[TCC] / IERH [TCC] bit would be set to generate a EDMA completion interrupt to the DSP.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Hi,

    Acoording to your suggestion, the TCC = 0.

    In my procedure, I set the IER[0] and the interrupt that raised is IPR[0].

    No transfer is done.

    The ERRSTAT is 0x9 and the ERRDET is 0x00010001

    The situation gets strage, while I changed the  source and destination addresses from L2 to DDR.

    Test #1:

    When SRC address is  DDR (0x80000000) and DST address is DDR (0x80001000) I got the completion IPR,

    ERSTAT was 0x8 (MMR error is always set as I wrote in one of my previous posts) and ERRDET is 0x0 (means no errors)

    but no transfer took place.

    The PaRam used : 0x8010000C  0x80000000  0x04000001  0x0x80001000

                                        0x00000000   0x0000FFFF  0x00000000  0x0000000001

    Test #2:

    When SRC address is  DDR (0x80000000) and DST address is L2 (0x880800) I got the completion IPR,

    ERSTAT was 0x9 (MMR error & BUSERR) and ERRDET was 0x0001009 (means write error -  L2 is destination)

    but no transfer made.

    The PaRam used : 0x8010000C  0x80000000  0x04000001  0x00880800

                                        0x00000000   0x0000FFFF  0x00000000  0x0000000001

    Test #3:

    According to what I got when I used SRC address in L2 (0x00880000) and DST address  in L2 (0x00880800), I got the IPR,

    ERRSTAT was 0x9 (MMR error & BUSERR) and ERRDET was 0x00010001 (means read error -  L2 is source and destination)

    but no transfer made.

    The PaRam used : 0x8010000C  0x00880000  0x04000001  0x00880800

                                    0x00000000   0x0000FFFF  0x00000000  0x0000000001

    It seems that there is a strange problem when using EDMA with L2, seen in the error indications.

    While when using EDMA with the DDR, no error indications are set but still the transfer in both settings no transfer is done.

    I don't see any major differences from the Block Move example in the EDMA document.

    and I wonder what is wrong?

    I saw also that when I don't set the STATIC bit in the OPT, most of the PaRam is cleared after triggering the transfer , is it normal?

    Don't the TC registers SAxxx (0x240 - 0x260) and the DFxxx (0x280-0x3D4) hold any information that can tells us something about the problem?

    Something like; if the transfer didn't start or if it  got stuck or anything?

    Thanks,

    Ilan.