Could dman3 configuration affect to edma channels of McBSP?

It is my understanding tha DMAN3 only uses QDMA channels as opposed to EDMA channels.

I think you should look at issues concerning shared transfer controller hardware and endpoints instead of transfer channels.  If your dman3 channels are requesting the same transfer controller or end point as your mcbsp channels, then it is possible that the dman3 transfer hogs the hardware and locks the mcbsp channel out until it is finished.  This would explain the behavior you described in your previous posts, where the mcbsp stops responding at a particular point for a particular period of time and then works again.  It would also explain why manually writing data to the transmit register works... the edma is servicing a higher priority /very long transfer and can't service the mcbsp.

Thanks a lot to both of you. I am thinking that like Matt say there is some conflict with dman3 channels. I have looked TCC0 registers and they show some error bits set. At this point I have to say that I have configured my edma channels using CSL and not in dman3 context. So I think I have two options:

a)The easy one for me: keep working as the same way and try to allocate my channels or allocate in other way dman3 channels to avoid conflicts. So, first I need to know what channels are really using the dman3 (see first post where is the configuration). I have been reading about DMAN3 configuration and my assumptions:
               -Channels from 78-126 are used.
               -TCCs from 32 to 63 are used too, so I should avoid to use 32-63 channels... is this right?

               a1: So... as long as I do not use that channels, I should be okay ???

               a2: I really need to use the 33 channel, can I just simply redefine the mask as 0xfffffffd and hope everything works??

I think I am missing something as although this considerations I can get it work rightly.

b)The best way could be enter in dman3 configuration, resource manager or something like that... but I do not have any ideas about dman3 and xdais, and documentation about this seems to me a little confuse. Could someone give some tips?

Could someone told me anything about a) or b) question??, I really need some help, this is driving me crazy.

Thanks in advance

I will confess that I am unfamiliar with using the dman3 since I rolled my own dma driver, but I will still attempt an explanation at a possible failure mechanism and see what others think.  There are 2 big blocks of the edma hardware on this chip:

1) The channel controller is basically the user interface.  This is where you have access to the 128 dma channels.  It's possible that your csl dma code and your dman3 3rd party app are trying to use the same channel, which would certainly cause funny behavior.  I don't think this is the cause, because your transfer eventually recovers and starts working again.  If your csl PaRAM set was overwritten by the 3rd party app, it would not recover unless you manually configured it again.

2) The transfer controller is the actual hardware that performs the dma movement.  There are 3 transfer controller blocks, and they are assigned to the channels by registers (dmaqn or something like that, its in the edma app note).  If multiple channels from the channel controller both request movement from the same transfer controller, there are priority registers that determine who wins.  I think this is the root of your problem.  If your 3rd party app has a higher priority or if it does a particularly long transfer on the same TC as your csl channel is assigned, you will get your described behavior: at a certain point, you lose dma service b/c another device has locked you out for a period of time.  Without knowing endpoints for your transfers, it is also possible that both transfers are trying to access DDR2, and access to that endpoint is again resolved by priority registers with the same general symptoms.

Thanks a lot Matt, I was thinking exactly as you described in 2). In fact one of my first ideas was to map my channels to another TC, for instance TC0 instead of TC1. I will keep it trying things. More tips?

Hello again, I really need some guru's advice to help me with this. To sum up:

                 -I have an application that use DMAN3 configuration
                 -I want to integrate in this application some edma channels to manage McBSP mainly.

How would be the way to integrate it? In the beggining, I have tried to avoid the channels that I though that dman3 is using and configure the channels that I want using CSL... but no luck with this. Is this impossible? It would be very good for me to forgive about dman3 as I do not have many experience with it. So, if someone think that this could be achieve, please let me know

In the other hand, I have been reading about edma LLD (low level driver) Resource Manager, to reserve channels using by my peripheral (McBSP)... but I think I would need to change the original DMAN3 configuration of my application too to do it, what I would like to avoid. Could someone give me some tips? I am quite lost right now and I would aprecciate any help.

thanks

A couple of points here:-

DMAN3 uses only QDMA channels, paRams and TCCs that it has been configured to use.

Say for e.g, that your DMAN3 configuration is as follows:-

    DMAN3.numQdmaChannels = 8;
    DMAN3.qdmaChannels = [0,1,2,3,4,5,6,7];

The above implies that all 8 QDMA channels on your device could be used by DMAN3 for allocation. Hence your drivers or other entities in your system should NOT be using any QDMA channels.

  DMAN3.paRamBaseIndex = 78;
    DMAN3.numPaRamEntries = 48;
    DMAN3.numPaRamGroup[0] = 48;
    DMAN3.numTccGroup[0] = 8;

The above implies that PaRam # 78 to PaRam# 125 are being used by DMAN3. No other entity in your system should use these PaRrams. Since these PaRams are all >=64, they do not interfere with the default mapping of EDMA channels used. Please make sure that no EDMA channels are being mapped to the above PaRams using the DCHMAP register.

    DMAN3.tccAllocationMaskL = 0;
    DMAN3.tccAllocationMaskH = 0xffffffff;

The above implies that TCC#s 32 to 63 will be used by DMAN3. Make sure your drivers etc do NOT use these TCCs.

Finally, in response to your earlier question, if you need to use TCC#33 for McBsp or some other EDMA trasnfer setup, you can change the DMAN3.tccAllocationMaskH to set bit 33 to zero etc, as you have mentioned. Re-build your application with the modified configurationa nd that should ensure that DMAN3 will not use those particular TCCs.

Some other information regarding DMAN3:-

1. By default, all QDMA channels are mapped to Queue#1. You could try setting up McBSP to use some other Queue for transfers

2. By default the priority of the Queue#1 (TC#1) is set to 7 and that of Queue #0 (TC#0) is set to 3 by DMAN3

Finally, some more details about the actual behavior you are observing would be great. Are your transfers getting stuck ?! Have you tried, setting up McBSP independently (without setting up DMAN3) ? Is there a reason you suspect interference from DMAN3 ?

Also more details on the errors you see in your registers would be good to have. What exactly do you mean by TCC#0 registers ?!

Also as Matt mentions above, we need more details regarding the "destination" of your EDMA transfers. Both the ones that use DMAN3, and the McBSP + CSL transfers. Do you have details on the transfers that are being performed using the EDMA ?!

One other point I forgot to mention, was the setting for DMAN3.nullPaRamIndex. This indicates a PaRam entry that is used as a "NULL PaRam" for configuring DMAN3. Set this to a PaRam entry that is NOT being used by McBSP etc. For e.g, set it to 127 etc. (Don't set it to the first 63 entries that EDMA channels might be using, or to the ones being assigned to DMAN3 for setting up transfers).

The default setting of "0" may not be suitable for your use-case.