• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 972 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C6748 EDMA3 setup

cobsonchael
Mastermind 7910 points
Other Parts Discussed in Thread: SYSBIOS

SO we are using

SYSBIOS 6.37.3.30

XDC 3.25.5.94

EDMA3 2.11.14

I am trying to use the EDMA3 but i am having weird problems.  my code is aborting at edma3init. it doesn't abort INSIDE that routine, it aborts upon the call of that routine. like when i step into it.  for some reason the linker gods aligned and it did not abort on me and i was able to accomplish a transfer.  but then i rebuilt after making a minor change and it would abort at edma3init. this routine is coming from the libraries i am linking in so i did not write it.  

what i want to know from start is do i have this project setup correctly for EDMA? is it in my project settings that is causing me to get these aborts? so here is what my setup is:

in my General->RTSC tab i have my edma3 checkbox checked with the most up to date edma3 i have installed

in my C6000 Linker->File Search Path->include library file i have:

"${EDMA3_LLD_INSTALL_DIR}\packages\ti\sdo\edma3\drv\sample\lib\c6748-evm\674\debug\edma3_lld_drv_sample.a674"
"${EDMA3_LLD_INSTALL_DIR}\packages\ti\sdo\edma3\rm\lib\c6748-evm\674\debug\edma3_lld_rm.a674"
"${EDMA3_LLD_INSTALL_DIR}\packages\ti\sdo\edma3\drv\lib\674\debug\edma3_lld_drv.a674"

where EDMA3_LLD_INSTALL_DIR is a variable i found but i cannot find where it is defined. however the project links without issue so i assume it points to whatever EDMA version i have checked in the RTSC tab

at the top of my edma c file i have

#include <ti/sdo/edma3/drv/edma3_drv.h>      /* EDMA3 defines */

extern EDMA3_DRV_Handle edma3init(unsigned int ,EDMA3_DRV_Result *);

static EDMA3_DRV_Handle hEdma;

here is the routine i use to call the edmainit:

BOOL InitializeEDMA3(void)
{
BOOL retBOOL = FALSE;
EDMA3_DRV_Result Error;

memset(hEdma, 0,sizeof(hEdma));
hEdma = edma3init(0, &Error);
if(Error == 0)
{
retBOOL = TRUE;
}

return retBOOL;
}

in the app.cfg file i have the event combiner enabled an event group 0 i have going to HWI 11 and event group 1 i have going to HWI 12. my aborts are happening, i believe, is because i have the exception mode handling memory protection

my gel file has every instance of the EDMA enabled in PSC which is in PSC0: 0,1,2 and in PSC1: 0, 21

so did i miss something? did i do something wrong? any idea why i would abort just on the CALL to the init routine (as if it linked wrong)? why would i work for a little while then a little code shuffling cause it to blow up again?

  • 0
    TI__Guru* 84110 points

    cobsonchael said:
    I am trying to use the EDMA3 but i am having weird problems.  my code is aborting at edma3init. it doesn't abort INSIDE that routine, it aborts upon the call of that routine. like when i step into it.  for some reason the linker gods aligned and it did not abort on me and i was able to accomplish a transfer.  but then i rebuilt after making a minor change and it would abort at edma3init.

    This is confusing. It would help to be in chronological order with details on what worked and what was changed. My guess is that it starts in the middle with the linker gods and getting a transfer to work. Then you changed something and now it aborts? The obvious thing to try is to back out the change you made and see if it works.

    The next thing to try is to close CCS, power cycle the board, and try it again. Something may get initialized once but needs to be initialized more often.

    Did you start from a working example? That is always the best way to go, since things that seem innocent (like memset on a handle) might cause problems.

    You could take a look at your linker map file to decide if everything looks like it was linked to the right place.

    How comfortable are you with C674x assembly? You do not need to be an expert to be able to read it and make some sensible guesses about what the instructions will do, at least in the case of trying to debug a problem like this. I recommend running to the C line where you call edma3init(), opening the Disassembler Window, and using the assembly step-into buttons in the Disassembler Window (assuming you are using CCSv6). There may be a few instructions that setup the call arguments and the return address, and some of these may be after the B branch instruction or around the CALLP instruction. Before taking the B or CALLP, open the Registers Window and look at the core registers to observe the value in whichever registers are being used for the B or CALLP. After either instruction, you will have to step 5-6 times before moving to the target location because of the pipeline. But you should end up at the edma3init() address, and it should be in good memory.

    You may need to get some screen shots from the disassembler to show us, if you are not able to find any specific problem before reaching that point.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Mastermind 7910 points
    thank you for your reply

    it is confusing, because i am confused. i was unable to find a working example because all of the projects that i imported for my DSP were unbuildable. i started by reading the super-uber-datasheet edma section, then watching the videos and going to the wiki. from there i used a pdf from the wiki that covers most of what is in the video but also covers code examples (it is a very dated document though). i named my routine edma3init and tried to build it and found linker errors because it was already defined. that is when i discovered the libraries for my DSP already have this routine defined so i decided to use that instead. everything linked fine. i am pretty sure that the biospsp SD card drivers use this routine so i assumed it was safe to use for my dsp (we have another project that uses the SD card PSP drivers. this board does not but uses the same DSP).

    the reason i am so confused is because it isn't consistent. it started out crashing at the call to edma3init. i did an assembly single step and the first or second thing it does is launch an exception for the abort. i can cannot step into this thing without it aborting. i checked and the routine links and has an address. i made a change to how the libraries are ordered and it worked a few times. i added some cache invalidate stuff and then it started to crash on the call again. i undid my change and it still crashed. i think the way it behaves is there is either a weird linker issue or there is a setting in the DSP that gets set and causes this thing to abort. on friday it was getting it to work and was able to do some complete DMA transfers. without changing anything in the code on monday when i came in and ran it again i had nothing but aborts since.

    i am not overly comfortable with the C674x assembly. i have never worked with it directly and the last time i did assembly was with an intel 8051. as i said before i never enter edma3init because 1 or 2 assembly instructions into the call i get redirected to interrupt 1 and from there exception.
  • 0 in reply to cobsonchael
    TI__Guru* 84110 points

    In your other thread, you showed an Exception listing. That can have valuable information, especially the value in NRP which is the address of the instruction that caused the exception, or the instruction after it (I cannot recall for sure, and it is may vary depending on the exception found).

    The fact that you have done some Brand X assembly means you can handle this, for sure. Single step until you get the exception, then start everything over and single step to the step just before the exception occurs. Then get the screen shots and relevant registers and send them to us. And I think there were other useful things mentioned in my previous post, but you may have tried those to no success - if so, please tell us that, because silence implies no action was taken, but running a test with no 'useful results found' does help to narrow the search.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Mastermind 7910 points
    so here is me putting my tail between my legs

    i commented out the memset of the edma handle pointer before the edma3init call and everything has been working just fine since then. i copied that directly from the example code but i didn't check it too closely because the code i stole it from the handle was an array and my handle is just the pointer.

    until i have further issues i think i am going to go hide now. thanks for your help! i do appreciate it.