• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 711 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

[solved]Problem on using EDMA3

Elric
Expert 1250 points


Solved: Matter is solved now, there were two problems, first one was, as already told, parameter set locations were unwritable. Second one was the way I was giving the destination address, later I noticed destination address was used as a double pointer in my app. Thank you. [Also another note, I used csl functions of c6455 with some modification such as structures and addresses and it works fine, so if anyone wants to use Edma3 without using the bios integrated drivers, this kind of solution can be applied.]

Hi,

I am experiencing a problem on using EDMA3. I don't use the provided EDMA3 driver. Instead, I am using a modified version of CSL codes of c6455. The addresses, structures and other related things are updated for the dm6437.

I am able to initialize the copy engine. When I call the function that triggers the copying, I get a interrupt (transfer completed interrupt I think?). But when I check the copy destination address, I see there is nothing copied.

I am checking my edma copy engine object to assure if the fields are filled correctly, there seems no problem. I also check some of the edma registers such as tc0 SASRC, SAOPT.. and I see they are filled correctly. For example, SASRC contains the source address of my array.

Do you have any suggestion why the copying does not happen?

Thanks in advance,

Erman

  • 0
    TI__Guru*** 125430 points

    If you're correctly getting the transfer completion interrupt then the IPR bit corresponding to your TCC value should be set.  Is that the case?  If you set TCINT=0 do you stop getting the completion interrupt?

    If you post the data in the Parameter RAM entry immediately before you initiate the transfer that would help diagnose the issue.

    Brad

  • 0
    Expert 2995 points

    What environment (UBL,u-boot, Linux) do you use?

    Are you aware of virtual and physical addresses?

    Also you could check error flags.

     

  • 0 in reply to Brad Griffis
    Expert 1250 points

    Thank you for answering.

    Brad,

    Yes, the corresponding bit in IPR is getting 1 after calling the function. I will try to set TCINT to 0 and look if it stops.

    However, I DON'T see any value in the Parameter RAM entries. I think this is a problem? All the parameter RAM entries are equal to 00000000 (in register window). When I try to look them from the memory window, I can't read the parameter entries locations, they are grayed out. Also when I try to write a value to a parameter RAM entry from the register window, it gives an error "memory map prevented to write target memory at 0x01C0...." It seems the source of the problem might be here. My parameter RAM entry registers are empty and not writable.

    Constantine,

    I am using CC under Windows. How should the phyiscal and virtual addresses can be related to my problem?

    Thank you,

    Erman

  • 0 in reply to Elric
    Expert 1250 points

    Edit to the above message:

    Now I am able to write or read to the Parameter RAM entries. Defaultly, they are not defined in the memory map function of the gel file. Why should they not define in the gel file, it is really strange.

    Anyway, now at least I am able to read and write to the Parameter RAM entries. And another thing I find is that tc0 ERRSTAT register's value is 00000001. This means EDMA3TC has detected an error at the source or dest address. And the ERRDET register's value is 00021A09. For the bits 0-3, 9h means there is an error at write addressing. When I check my Parameter RAM DST register, which is destination address register, I see it's value is 0x00000000. My problem's source may be here.

  • 0 in reply to Elric
    TI__Mastermind 37340 points

    Elric said:

    I am using CC under Windows. How should the phyiscal and virtual addresses can be related to my problem?

    When using CCS, make sure hardware EVM is in known stable state (e.g. break into u-boot or put EVM in serial boot mode).  If you let Linux boot and try to connect with CCS, you may see interference by the Linux kernel trying to boot which may result in weird behavior (e.g. overwritting registers set by GEL...).

    When using CCS, you do not need to worry about physical to virtual translation (this is a Linux thing); putting the hardware in known good state simply provides a more stable working environment.

  • 0 in reply to Juan Gonzales
    TI__Guru*** 125430 points

    Constantine/Juan,

    Unless I've badly misread something, the original post mentions this is for DM6437 so there should not be any u-boot, Linux, virtual-to-physical address mappings, etc.  He already figured out that it was the CCS memory map messing things up.

    Elric,

    Yes, the incorrect DST (0x00000000) appears to be causing your problem.

    Brad

  • 0 in reply to Brad Griffis
    TI__Mastermind 37340 points

    Brad,

    Thank you for poiting this out; I should have read the entire thread isntead of just the last portion.  u-boot and virtual addresses do not apply to DM6437.

  • 0 in reply to Brad Griffis
    TI__Mastermind 41665 points

    This is why we should probably seperate the forums into ARM based and DSP only based Davinci processors, the differences are significant and I have made the same mistake assuming one processor type or the other more than once.