C6455 DMAs Setup

Specifically, we have a C6455.  We have EMIF connected to an FPGA that acts as a FIFO.  A low falling edge on GPIO Pin4 signals us the FIFO is ready to be read.

I'd like to simply do an A-synchronized read of roughly 5000 32 bit values from EMIF into memory.  This shouldn't be too hard, but I can't get the transfer to occur.

I followed the c6455-csl_03_00_10_02/csl_c6455/example/edma/edma_interrupt example.

I, however, am using SYS/BIOS 6.33.4.39 and am not using the INTC module from the CSL.  So I may be doing something wrong.

But I don't even get the DMA occurring... much less calling my ISR (which I setup through BIOS).  I see that the GPIO pin is set to FAL_TRIGGER and as an INPUT.  I turned on the BINTEN bank interrupt enable.  Maybe I'm missing a step.  :(

I can provide code if that would help.

FF,

There seem to be a variety of issues here, so I may not address them all but this should all be able to work.

One thing I am confused about is the while loop + ISR. Usually, a while loop is polling for a GPIO bit to change, so the ISR would be used instead of that while loop. Can you explain the use of the while loop and the ISR together? If you had an ISR being called based on a transition of the GPIO pin, then that is a good step. But in this case it sounds like you might have been polling instead, and in any case you do not want that ISR anymore because the EDMA3 should cause your interrupt once the actual data transfer is completed.

The GP[4] can be setup to cause an EDMA3 event to trigger DMA channel 52. Using CCS, can you examine the registers DCHMAP52, EMRH, ERH, EERH, SERH, IPRH, IERH, and the PARAM for Channel 52 and any link PARAMs. Please post the hex values for those.

As a test for the EDMA being configured, try writing (1 << (52-32)) to ESRH to manually trigger the DMA channel, then look at memory to see if you are getting data written to the destination.

Regards,
RandyP

Randy,

      Thanks for the quick reply.  I'll rephrase slightly.  Before we started doing any DMA work, our FPGA would set GPIO Pin4 low, and we had attached an ISR to that event.  Inside the ISR, we would read our data with a while loop.  So no, we weren't whiling on the GPIO bit.  We were getting an ISR on the GPIO, and then reading the data in a while loop.  Now we're trying to DMA it out instead.  I'll try that debugging and get right back to you.  Thanks!

DCHMAP52 : 0x0000 0680

EMRH : 0x0000 0000

ERH :  0x0010 0000

EERH : 0x0000 0000

SERH : 0x0000 0000

IPRH : 0x0000 0000

IERH : 0x0000 0000

Here's the PARAM for Channel 52 from within CCS

PARAMSET_52_OPT 0x80134201 Option [Memory Mapped]
PRIV 1 - SUPERVISOR Privilege level
_RESV 000 Reserved
PRIVID 0000 Privilege ID for external host/cpu/dma
ITCCHEN 0 - DISABLE Intermediate transfer completion chaining enable
TCCHEN 0 - DISABLE Transfer completion chaining enable
ITCINTEN 0 - DISABLE Intermediate transfer completion interrupt enable
TCINTEN 1 - ENABLE Transfer completion interrupt enable
_RESV 00 Reserved
TCC 110100 Transfer completion code
TCCMODE 0 - NORMAL Transfer completion mode
FWID 010 - 32 Fifo Width
_RESV 0000 Reserved
STATIC 0 - NORMAL Static entry
SYNCDIM 0 - ASYNC Transfer Synchronization Dimension
DAM 0 - INCR Destination address mode
SAM 1 - FIFO Source address mode

PARAMSET_52_SRC 0xD0000600 Source Address [Memory Mapped] 

SRC 11010000000000000000011000000000 Source Address

PARAMSET_52_A_B_CNT 0x00015000 A Count [Memory Mapped]
BCNT 0000000000000001 B Count
ACNT 0101000000000000 A Count

PARAMSET_52_DST 0x008A8300 Destination Address [Memory Mapped]
DST 00000000100010101000001100000000 Destination Address

PARAMSET_52_SRC_DST_BIDX 0x00000000 SRC B Index, DST B Index [Memory Mapped]
DSTBIDX 0000000000000000 Destination B Index
SRCBIDX 0000000000000000 Source B Index

PARAMSET_52_LINK_BCNTRLD 0x0001FFFF Link Address [Memory Mapped]
BCNTRLD 0000000000000001 B Count Reload
LINK 1111111111111111 Link Address

PARAMSET_52_SRC_DST_CIDX 0x00000000 Source C Index [Memory Mapped]
DSTCIDX 0000000000000000 Destination C Index
SRCCIDX 0000000000000000 Source C Index

PARAMSET_52_CCNT 0x00000001 C Count [Memory Mapped]
_RESV 0000000000000000 Reserved
CCNT 0000000000000001 C Counter

FF,

Yes, the fact that the ESRH write filled your buffer means that the DMA PARAM is set somewhat correctly. You need to clear SAM since nothing on the C6455 supports the FIFO/constant addressing mode; use the correct indexing instead with SAM=0; And for my sake, please clear FWID because I never see that field set and I confuse easily.

ERH.bit52=1 means that you are getting an event to the EDMA3 from GP[4], which is good news. But EERH needs to have that same bit set before the event will trigger a transfer. This needs to be added to the program. The IERH bit also must be set before the completion of the transfer (which sets IPRH.bit52) will generate an interrupt; this also needs to be added to the program.

If IPRH gets set and IERH is set, and if you have EDMA3CC_GINT routed to a DSP interrupt and the corresponding bit in [the other] IER is set, you should get your ISR triggered.

Regards,
RandyP

RandyP said:

FF,

1.) You need to clear SAM since nothing on the C6455 supports the FIFO/constant addressing mode; use the correct indexing instead with SAM=0;

2.) And for my sake, please clear FWID because I never see that field set and I confuse easily.

1.) "Use the correct indexing instead of SAM = 0" ???  Happy to.  I thought using FIFO mode was what I should be doing to talk to a FIFO.  How should I change the indexing to act like FIFO mode?  I'm not sure I know what you mean by that.

2.) I was just trying to read 32-bit-width data.  Is FWID the wrong way to do that?  Our EMIF is 32 bits wide.  (Not using the top 32 bits of EMIF data lines.)  Does this happen automagically somewhere?  (Doubting this is the case.)  I just assumed I needed to specify the word transfer width.  No?

FF,

FastFourier said:

1.) "Use the correct indexing instead of SAM = 0" ???  Happy to.  I thought using FIFO mode was what I should be doing to talk to a FIFO.  How should I change the indexing to act like FIFO mode?  I'm not sure I know what you mean by that.

Somewhere in the datasheet or EDMA3 User's Guide, it says FIFO mode is not supported. Or more specifically, it will say that it is supported if you come across an internal peripheral that does support it. This has been discussed on the forum before, so a search on some of the relevant terms should find some other discussions on it.

"use the correct indexing instead with SAM=0" was written poorly. "use the correct indexing with SAM=0" is better. Do not use SAM=1 or DAM=1. If you want all the reads to be from the same address, then use ACNT=4 and SRCBIDX=0 and BCNT=0x5000/4 and OPT.SYMCDIM=ABSYNC.

FastFourier said:

2.) I was just trying to read 32-bit-width data.  Is FWID the wrong way to do that?  Our EMIF is 32 bits wide.  (Not using the top 32 bits of EMIF data lines.)  Does this happen automagically somewhere?  (Doubting this is the case.)  I just assumed I needed to specify the word transfer width.  No?

If you configured the EMIF to be 32-bits wide for the addressing space of the FIFO device, then all accesses will use the defined bits. See the EMIF User's Guide for a more complete explanation and to see which bits are used.

Please describe how you want the FIFO device accesses to run.

Regards,
RandyP

RandyP said:

Somewhere in the datasheet or EDMA3 User's Guide, it says FIFO mode is not supported. Or more specifically, it will say that it is supported if you come across an internal peripheral that does support it. This has been discussed on the forum before, so a search on some of the relevant terms should find some other discussions on it.

"use the correct indexing instead with SAM=0" was written poorly. "use the correct indexing with SAM=0" is better. Do not use SAM=1 or DAM=1. If you want all the reads to be from the same address, then use ACNT=4 and SRCBIDX=0 and BCNT=0x5000/4 and OPT.SYMCDIM=ABSYNC.

OK.  I'll make the changes and see if I can get this up and running this morning.

RandyP said:

If you configured the EMIF to be 32-bits wide for the addressing space of the FIFO device, then all accesses will use the defined bits. See the EMIF User's Guide for a more complete explanation and to see which bits are used.

And that's what we've done, so I'll unset that FWID bit.

FF,

The CSL comes with examples that show you how to enable a channel. The CSL_edma3HwChannelControl() function has an argument selection that will enable a channel.

If you search this forum for "c6455_edma" (no quotes) and look at the most recent one with a file attachment, you can use that example, too. It corrects some errors in some of the old C6455 CSL examples, but those may have been fixed. It does not use external events, so it does not enable a channel.

Regards,
RandyP

Alright.  We're so close here!  I'm getting DMAs and they're filling the buffer completely.  Great news.  Thanks for the help Randy.

The only issue left is that my ISR is not triggering.

In my SYS/BIOS .cfg file, I have hooked the function "EDMA_isr()" to event #24, which should be EDMA global completion event.  

It seems like I'm going wrong in my code where I try to enable interrupts from the EDMA CSL module.

regionIntr.region = CSL_EDMA3_REGION_GLOBAL;
regionIntr.intr = 1 << 24;
regionIntr.intrh = 1 << (20);

status = CSL_edma3HwControl( hModule, CSL_EDMA3_CMD_INTR_ENABLE, &regionIntr );

if( CSL_SOK != status )
{
return -1;
}

When I do the following, I get no interrupt

regionIntr.region = CSL_EDMA3_REGION_GLOBAL;
regionIntr.intr = 1 << 24;
regionIntr.intrh = 0;

I thought regionInt.int = 1<<24; would enable event #24, which would be Global EDMA Complete, but apparently I'm misunderstanding the bit masks in intr and intrh.  Is there some documentation on what those bits are/mean that I can use to select the correct bits?  Thanks again for all of the help!

I was misunderstanding what intr and intrh meant in the context of edma.  I thought I was supposed to enable the bit for the global edma completion interrupt, with is 6455 interrupt 24.  But the EDMA intr and intrh refer to edma channels, which upon completion, we want to trigger that global completion interrupt.  Now I've got it working.  Things are working pretty smoothly now, and I'm on to migrating other code to DMAs.  Thanks for the help Randy.  I'd mark it as answered, but it's Hector's thread.

RandyP.  Thanks for all of the help.  I'm about to ask for some more, and it's a topic you've covered on the forums here before.

Chaining.  :/  So, I read this thread and this thread, and downloaded your fixed CSL chaining example.  I fixed a couple little things from the example, but I can't get the chaining to happen.  Actually, I have two bugs.  I'll explain the idea of the DMA I'm trying to do, and then what's not working.  Maybe the bugs are really the same bug.

So, in the beginning of this thread I was doing our trivial DMA of a read of just one FIFO into an array in memory.  Now I need to add a different DMA type for other data coming from our FPGA FIFOs.  In fact, this involves reading EIGHT (8) FIFOs.  Four of one data size, and four of another.

So, from FIFO type A, I need to read 30 complex16_t's.  So 16 bits of I and 16 bits of Q in each complex16_t.  32 bits * 30.  There are four of these FIFOs I need to empty.

From FIFO type B, I need to read a different amount.  Anywhere from 10 to hundreds of complex16_t's.  And there are four of these FIFOs.

So here's how I thought I would do it.  

Type A :   The idea is that each FIFO will be emptied by an AB synchronized transfer (just like in the previous DMA we did above), but then we'll do CCNT = 4 of them, with CSrcDst Indexing jumping to the next FIFO and the next buffer.  I plan to ping pong buffers so you'll see a LINK address below.

PARAMSET_53_OPT 0x80506004 Option [Memory Mapped]

PRIV 1 - SUPERVISOR Privilege level
_RESV 000 Reserved
PRIVID 0000 Privilege ID for external host/cpu/dma
ITCCHEN 0 - DISABLE Intermediate transfer completion chaining enable
TCCHEN 1 - ENABLE Transfer completion chaining enable
ITCINTEN 0 - DISABLE Intermediate transfer completion interrupt enable
TCINTEN 0 - DISABLE Transfer completion interrupt enable
_RESV 00 Reserved
TCC 000110 Transfer completion code
TCCMODE 0 - NORMAL Transfer completion mode
FWID 000 - 8 Fifo Width
_RESV 0000 Reserved
STATIC 0 - NORMAL Static entry
SYNCDIM 1 - ABSYNC Transfer Synchronization Dimension
DAM 0 - INCR Destination address mode
SAM 0 - INCR Source address mode

PARAMSET_53_SRC 0xC0001060 Source Address [Memory Mapped]

PARAMSET_53_A_B_CNT 0x001E0004 A Count [Memory Mapped]

BCNT 0000000000011110 B Count
ACNT 0000000000000100 A Count

PARAMSET_53_DST 0x008A0F80 Destination Address [Memory Mapped]

PARAMSET_53_SRC_DST_BIDX 0x00040000 SRC B Index, DST B Index [Memory Mapped]

DSTBIDX 0000000000000100 Destination B Index
SRCBIDX 0000000000000000 Source B Index

PARAMSET_53_LINK_BCNTRLD 0x00004020 Link Address [Memory Mapped]

BCNTRLD 0000000000000000 B Count Reload
LINK 0100000000100000 Link Address

PARAMSET_53_SRC_DST_CIDX 0x00780080 Source C Index [Memory Mapped]

DSTCIDX 0000000001111000 Destination C Index
SRCCIDX 0000000010000000 Source C Index

PARAMSET_53_CCNT 0x00000004 C Count [Memory Mapped]

_RESV 0000000000000000 Reserved
CCNT 0000000000000100 C Counter

Type B :  Exactly the same as Type A, but potentially much more data.  Type B will be chained from A.  B will ping and pong as well.  The same CCNT = 4 and indexing will be used.

PARAMSET_6_OPT 0x80107004 Option [Memory Mapped]
PRIV 1 - SUPERVISOR Privilege level
_RESV 000 Reserved
PRIVID 0000 Privilege ID for external host/cpu/dma
ITCCHEN 0 - DISABLE Intermediate transfer completion chaining enable
TCCHEN 0 - DISABLE Transfer completion chaining enable
ITCINTEN 0 - DISABLE Intermediate transfer completion interrupt enable
TCINTEN 1 - ENABLE Transfer completion interrupt enable
_RESV 00 Reserved
TCC 000111 Transfer completion code
TCCMODE 0 - NORMAL Transfer completion mode
FWID 000 - 8 Fifo Width
_RESV 0000 Reserved
STATIC 0 - NORMAL Static entry
SYNCDIM 1 - ABSYNC Transfer Synchronization Dimension
DAM 0 - INCR Destination address mode
SAM 0 - INCR Source address mode

PARAMSET_6_SRC 0xC00010C0 Source Address [Memory Mapped]
PARAMSET_6_A_B_CNT 0x000A0004 A Count [Memory Mapped]
BCNT 0000000000001010 B Count
ACNT 0000000000000100 A Count

PARAMSET_6_DST 0x008A2580 Destination Address [Memory Mapped]
PARAMSET_6_SRC_DST_BIDX 0x00040000 SRC B Index, DST B Index [Memory Mapped]
DSTBIDX 0000000000000100 Destination B Index
SRCBIDX 0000000000000000 Source B Index

PARAMSET_6_LINK_BCNTRLD 0x00004100 Link Address [Memory Mapped]
BCNTRLD 0000000000000000 B Count Reload
LINK 0100000100000000 Link Address

PARAMSET_6_SRC_DST_CIDX 0x0A000080 Source C Index [Memory Mapped]
DSTCIDX 0000101000000000 Destination C Index
SRCCIDX 0000000010000000 Source C Index

PARAMSET_6_CCNT 0x00000003 C Count [Memory Mapped]

I am initiating a transfer (for now) via the following call.

   CSL_edma3HwChannelControl( hDMA_channel_TypeA, CSL_EDMA3_CMD_CHANNEL_SET, NULL );

So, here are my two bugs...

1.)  The C transfers from Type A don't appear to be occurring.  The first transfer happens, but the remainder don't.

2.)  The chain never gets executed, and that may be because of bug #1... i.e. the transaction it relies upon isn't completing.

So... did I setup Type A incorrectly?  Any clues as to what I'm doing wrong?

And are there things like "code" tags on this forum that will allow me to paste code in and have it maintain formatting and tabs etc?

Thanks Randy.

I just tried an experiment, where I set CCNT = 0 on TypeA.

I got one chained DMA event.  However, it exhibited the same problem as type A transfers.  Only one of the FIFOs was read and only one buffer filled.  As if CCNT == 0.  I feel like I'm setting up the CCNT incorrectly in both cases.  

Maybe my CsrcDst indexing doesn't work the way I think it works.  

I've been single stepping this some more.  The CCNT gets decremented from 4 to 3... but never beyond that.  If I setup the transfer to have CCNT = 1, then it decrements to 0 and the chain executes.  But nothing I've found so far is getting this to work with CCNT > 1.  Is there some restriction on AB+C transfers?  I wouldn't think so.  But something hates me here.  

I theorized that maybe it was related to the FPGA not being ready for a transfer.  Maybe something with EMIF lines not being ready for a read or something.  So I made the Source Address 0x0080 0000.  It's just some spot in code.

The DMA still didn't do cCnt = 4 transfers.  It only did one.  The PaRAM for the channel decremented to 3.  But it didn't go any further.  Also, it verified that I'm indeed copying in a FIFO-read style as the value at 0x0080 0000 was copied 30 times.

But still no working cCnt.  :(

I've found that if I call ...

CSL_edma3HwChannelControl( hDMA_FIFO, CSL_EDMA3_CMD_CHANNEL_SET, NULL );

once for every cCnt, then it completes and chains.  Is this to be expected?  I thought just one event would trigger all 4 cCnt transfers.

FF,

Just FYI and unrelated to your issue, your hex value for PARAMSET_53_OPT 0x80506004 does not match the value for TCINTEN 0 in the text below it.

Any trigger, an event, chain, or ESR, will cause one transfer request to be sent. This will either be an ASYNC or ABSYNC transfer. There is no ABCSync.

You have two choices:

1. The easiest is to use multiple DMA channels, one for each FIFO to be read. You can do the chaining from one to the next. This requires some duplication and the use of several DMA channels, but you have 64 of them available so why not.

2. The tougher way is to use self-chaining and linking to do all of this with a single DMA channel. Program the Active PARAM set with the Type A just as you originally did, but with OPT.TCC=53 and ITCCHEN=1 in addition to TCCHEN=1. The first set of FIFOs will be read one at a time, then the LINK will occur to read in the parameters for the Type B set. That Link set needs to also have OPT.TCC=53 and ITCCHEN=1, but TCCHEN=0.

Regards,
RandyP

Yeah.  I was playing with different bits in the OPT field trying to figure out if I had misconfigured something.

This is when that FIFO addressing mode would be nice on EMIF, because I could do this all with AB-sync.  B vectors of A length would do it.

My challenge here is that I'm GPIO limited.  Right now I'm triggering this manually to test the DMAs and make sure that they're working (which they're not).  In the end, our FPGA would hit a GPIO pin to trigger this whole DMA.  However, I only have 12 GPIO pins available to me, and I have MULTIPLE FIFOs.  This set of 4+4 FIFOs is just the tip of the iceberg.  I need to have as many of these as I can, as they represent data sources in our FPGA that we would replicate.  One goal of the design is to maximize that number.

Since it's an FPGA, and myself and another engineer designed it, it would be easy to pulse that pin 4x to make the 4 CCNT transfers happen.  But what about the chained DMA transfer?  Could I do intermediate chaining to kick off one of those after every TYPE A transfer completes?  (i.e. if I have CCNT == 4 of the TYPE A transfers, can I trigger a chained TYPE B transfer after every single CCNT == [1,2,3,4] TYPE A transfers?)  Is that what intermediate chaining does?  ITCCHEN?

The other option would be to spread all of our FIFOs out in FPGA address space.  These FIFOs have an entire EMIF chip select to themselves.  We could then use incremental address mode and do B transfers of length A and not worry about the lower bits of the address which would be incrementing.   Hmmmm.  That might be the easiest option.  I can shuffle addresses really easily.

Let me know your thoughts if you don't mind.  I'll be fiddling with this today, but if I'm heading down a path you know will break, please raise the warning flag.  :)  Thanks for all of the help so far.

We may have discussed this before, but in the Training section of TI.com, there is a training video set for the C6474. In particular, the EDMA3/QDMA/IDMA Module may help you understand some of the features and options available within the EDMA3 module. There are some differences between the C6474 and the C6455 EDMA3 implementations, but the basics of operation are the same. I believe chaining and linking are discussed there. You can find the complete video set here.

The "easy" option 1 above was meant to use a single trigger event, such as GPINT0, to trigger a sequence of transfers without the need for any other external events. Only the one GPIO would be used, not one for each FIFO.

GPIO0 triggers DMA channel 48, since that channel is assigned to GPINT0. DMA channel 48 transfers the contents of the first TypeA FIFO using ABSync, CCNT=1, TCCHEN=1, and TCC=3. After the transfer of this first TypeA FIFO has completed, channel 48 will chain to DMA channel 3.

DMA channel 3 transfers the contents of the second TypeA FIFO, using ABSync, CCNT=1, TCCHEN=1, and TCC=4. After the transfer of this second TypeA FIFO has completed, channel 3 will chain to DMA channel 4.

DMA channel 4 transfers the contents of the third TypeA FIFO, using ABSync, CCNT=1, TCCHEN=1, and TCC=5. After the transfer of this third TypeA FIFO has completed, channel 4 will chain to DMA channel 5.

And so on. The last channel in the chained sequence will have TCCHEN=0. All of the transfers will occur in sequence without any external or manual triggering other than the first GPIO to start the process.

If you do the address ambiguation (if that is the right fancy word for it), then you can do all the TypeA transfers from a single event, then you could chain to a second DMA channel that will do the TypeB transfers. That would be a good way to go.

Regards,
RandyP

Thanks Randy.  We're going to try "FIFO Ambiguation" as a quick and easy change to make sure it all works.  If that works, there may not be any motivation to do anything else.  I'll let you know when I know if it works.  :)  It should.  Thanks again for the info.

Works perfectly.  :D  Thanks for the help Randy.

I'll post a longer more detailed "solution" for future Googlers tomorrow.