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.

C6678 EDMA3 Example never triggers the callback function



I'm working with the C6678 EVM using CCS 5.1.0.09000.  I have successfully built the edma3_drv_bios6_c6678_st_sample project.  When I run the debugger, the callback function registered in the EDMA3_DRV_requestChannel call never gets triggered.  Running the project, the debugger is stuck in the "waiting for interrupt..." loop.

As far as I can tell, the example is using channnel 0.  I've paused the debugger while it's waiting for the callback, and examined the appropriate registers (I think).  I see the tpcc_ier = 0x01 (which matches my channel number).  The tpcc_ipr also is a 0x01, which implies that an interrupt is pending for channel 0.

The ControlRegisters.IER does have some interrupts disabled (4, 5, 6, 11, 12, 13, and 15).  Is one of them masking my EDMA3 transfer complete interrupt, thus keeping my callback function from being called?

I do notice that the last line in the Console window when the GEL file completes is a "Disable all EDMA3 interrupts and events."  Is there something I need to do to enable the EDMA3 interrupts?

Any suggestions would be greatly appreciated.

  • I've spent another frustrating day trying to resolve this issue.  I'm obviously doing something stupid, but I don't understand why an example provided with the EVM kit doesn't function.  I've tried to tweak the code by adding CSL_intcInit calls that I found in another post, but nothing I've tried has had any affect.

    Has anyone successfully run the edma3 examples with the C6678?

    What is the purpose of providing callback functionality in the EDMA3_DRV_requestChannel function if it requires additional interrupt mapping or setup calls?

    I have a working edma3 project that uses EDMA3_DRV_waitAndClearTcc.  This project successfully transmits 160, 512 byte packets using the manual trigger mode for the EDMA3.  It was based on the supplied edma3 example, modified for my specific application (transferring a large buffer to an FX3 USB chip attached via the EMIF16 bus).  My EDMA3 transfers are working great with the polling method, but I needed to instead use a completion interrupt.  I assumed the callback option would be relatively pain free, especially since it was used in the example, but I've spent three days and I'm not making any progress.

  • I see that this post has been viewed over 120 times.  I know only half of that is me checking in to see if anyone has replied, so someone is reading this. 

    Is this the wrong forum to ask this question?

    Is there anyone who has successfully run the EDMA3 samples?

    I've tried many things with my own project, and I'm sure I've screwed it up somehow so it won't properly call the ISR, but I haven't changed the example code at all and it also does not get to the callback routine. 

    If anyone has any experience using the EDMA_LLD with interrupts enabled for intermediate transfer complete, and transfer complete, please give me a hint. 

  • I found another post (from last August) that seems to match the trouble I'm seeing:

      http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/126327/461644.aspx#461644

    In it, Dan Rinkes mentions McSDK version 2.0.1.12 and EDMA3 LLD version 2.11.2.4 and says:

      "I just rebuilt and ran the edma3_drv_bios_c6678_st_sample example with that revision and didn't have any problems executing it."

    He also posted a link to his debug .out file.  I've downloaded that file and it does indeed run successfully, which confirms that my EVM and debugger are running properly. 

    When I build the included example project and run the debugger,  it (like the post referenced above) stays indefinitely in the "waiting for interrupt" loop.

    I obviously have something built wrong.  My example project would not build properly at first.  I realized the .CFG file was (for some reason) not part of the project, so I copied it in.  Then the project built without errors, but it will not run.

    Dan also mentioned that he posted his EDMA LLD directory to the FTP site.  Can someone tell me how to find that so I can see why his version works and mine doesn't?

    I'm using McSDK version 2.0.6.18 and EDMA3 LLD version 2.11.3.3. 

  • Hi Andrew,

    I'm trying to get someone from the 6678 MCSDK team who would better know how to help you with your problem to chime in.

    In the meantime, I would suggest creating a new CCS workspace and try to import the example there and build.

    However, one issue I foresee is that the project you have been working with may have been pointing to the original example files that came with your MCSDK installation (instead of a copy of the example in your work space).  In this case, the original example would contain any modifications you made.

    You can check if this is the case by looking at your project properties and seeing if any of the files reside on disk within your MCSDK installation.

    If this is the case, you would need in re-install the MCSDK product to get the original examples.  I'm guessing that you can keep your original MCSDK installation and re-install into a different directory and just copy in the originals from that.

    Steve

  • Thanks, Steve.  I'll give that a try.  This has been a frustrating experience because I'm new to the C6678 and was hoping to come up to speed a little using the included examples.  When I couldn't get the edma3-lld example to work, I went through the forums looking for help, and wasn't getting any.  I finally found some posts on using CSL instead of the edma_lld libraries and had some minor success with an example posted there.  Still, that example proved to be frustrating too because it only worked when a 'printf' was included in the "wait for interrupt" loop.  When I removed the "printf", things went to lunch.

    Finally, yesterday, after spending a fruitless week trying things and examining registers in the debugger, I finally realized that the example was using local variables when setting up the CSL event handler.  Having the event handler arrays allocated on the stack allowed the first interrupt to trigger normally, but as the stack pointer moved around with various API calls within the ISR (to clear pending registers, etc) the ISR address pointer was overwritten.  When the second interrupt triggered, an invalid ISR address was used, causing the PC to be loaded with an address from the data space, which ended up triggering an invalid op code exception.

    Apparently, when the "printf" call was included, enough extra stack space allocated so the API calls within the ISR overwrote other things, and left the original ISR address pointer alone.

    When I moved the CSL event handler variables out of the local scope of the initialization function into global memory space, the CSL based edma3 transfer operated as I expected it to.

    I am still interested in getting the edma3_lld example to work, but more for curiosity than for need.  I can move forward with my project using the CSL based API.  I will experiment with the edma3_lld example as I have time, and will let you know if I have any success.

  • I'm having a very similar problem.  Not using the project as is strictly because I have a custom board but I've tried to replicate the example as closely as possible.  I too get stuck waiting for the interrupt (the callback to be triggered).  The transfer occurs but the callback never gets called and i sit in the while loop forever.  The polling example works just fine.  Any suggestions are appreciated.  I've been stuck on this for days.  I'll look into the above suggestion but otherwise I'm running out of ideas.

  • I figured out my mistake.  i was missing the Startup module. I'm guessing the HWI stack initialization here is required and the initilization in the HWI module is not sufficient.