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.

EDMA Interrupt Clear Register

Hey folks,

I'm working with the EDMA3 module to talk to the VCP2 on a C6455.  I'm using shadow region 4 (configured via DRAE/H) to split up this DMA functionality from some other DMA transfers that will be unrelated (otherwise I'd use the global region).

My problem is that the first VCP2 transfer works perfectly, and the completion interrupt is triggered correctly.  However, when the ISR writes to the Interrupt Clear Register (using CSL:

regionIntr.region = CSL_EDMA3_REGION_4;
regionIntr.intr = 1 << CSL_EDMA3_CHA_VCP2REVT;
regionIntr.intrh = 0;
CSL_edma3HwControl(hModule, CSL_EDMA3_CMD_INTRPEND_CLEAR, &regionIntr);

This seems to have no effect on the Interrupt Pending Register.  So, even though my second VCP2 transaction goes off without a hitch, I never get interrupted because the Interrupt Pending bit is still high.  I have set the DMA Region Access register with appropriate masks for my TCCs (which I have set to be identical to the event IDs for the VCP2), and I have (obviously) enabled those interrupts.

Any suggestions as to why I can't clear the "pending" bit?  Thank you!

Colin

  • With just this snippet, everything looks fine. It is very much the same as some of the CSL example files.

    My first thought was that the VCP2REVT constant was >= 32, but that does not seem to be the case. To avoid concerns with that, I like to use the following for the regionIntr fields:

    Code example said:
        unsigned long long            llTemp;

        llTemp  = (unsigned long long)1 << tccNum;
        regionIntr.intr = _loll(llTemp);  
        regionIntr.intrh = _hill(llTemp);

    My suggestions for finding the cause and solution:

    1. Set intr & intrh = 0xffffffff and see if your IPR bit gets cleared.
    2. Try the GLOBAL region for this. No reason for this to work, but something to try. I do not use regions with the C6455, but there can be a few cycles advantage if you do.
    3. Check your ISR and EDMA Dispatcher (if you are using one) to see if they might be interfering.
  • I tried setting intr and intrh to 0xFFFFFFFF, but it had no effect.  I also tried using the global region (still using 0xFFFFFFFF bit masks), and that had no effect either.  I am not using a dispatcher at the moment.

    Thanks for your suggestion regarding the use of unsigned long long.  I was fully aware of the VCP2REVT constant being < 32, but yours is a good general method for doing that.

    Colin

  • Time to temporarily put the status overhead back in.

    Code example said:
        CSL_Status                  status;

        regionIntr.region = RegionNum;
        llTemp  = (unsigned long long)1 << tccNum;
        regionIntr.intr = _loll(llTemp);  
        regionIntr.intrh = _hill(llTemp);
        status = CSL_edma3HwControl(hModule,CSL_EDMA3_CMD_INTRPEND_CLEAR,&regionIntr);   
        if (status != CSL_SOK)
        {
            return;
        }

    You can put a breakpoint on the return or the if statement. I am sure there is a clever way to get the error code into text, but the way I do it is to do a desktop search for "#define CSL_SOK" in .h files and there is the list of error codes. Near the top of csl_error.h is where I found them. I am sure they are in one of the documents, too, but I am lazy and header files open quicker than pdf's.

    Let us know what error code, if any, you get here.

    Another thing to try is to write 0xffffffff to IPC in CCS just to make sure there is something working right.

  • The status code was 1 (CSL_SOK).

    Writing to the interrupt clear register in CCS did clear the interrupt pending bit.  Am I missing a step?

  • Run to a breakpoint at the hwControl call, then add hModule to the Watch window. Click the + sign to open it deeper, and find regs. You may need to change the display format to hex, and then it should propagate to everything lower. Open regs, which will give you all the registers and look through to see what might be different than you would expect (EMR, SER, ER, IPR, as good examples).

    Using the ICR register in there, write the single bit value and see if it clears IPR. If not, try 0xffffffff (or -1).

    You can try debugging into the hwControl function, which means assembly and core registers and pipeline delays, which might not be a pleasant experience.

    Do you change the Supervisor/User mode for your program? I do not know that this would have an effect, but I have never changed that, just like I never use regions unless I have to.

  • Well, that sure did expose the problem: pilot error :-)

    I had been moving code around from previous tests and from existing samples, and ended up trying to use hModule after all its context was invalidated in freed stack space.  Seeing the registers in the hModule Watch window become garbage after a certain point in my debug execution was a nice big red flag.  Slap on the wrist for me.

    However, I will definitely be using that hModule Watch window in the future if I need to debug.  I didn't know I could examine all of the registers (in context) that way.  Thanks for your help and patience!

    Colin