Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

TSE with SGDMA Busy problem

I have a system with 2 CPUs. I have a working system where I have connected up a TSE to 2 seperate SGDMAs (Rx & Tx) and 2 seperate memories (Rx & Tx) which is controlled by the first CPU.

We needed to modify the system such the 2nd CPU now controls the system system. All I did is I changed the connections of the first CPU to the memories, SGDMAs and TSE and replaced them with the 2nd CPU. When we tried to trasnfer data via a loopback (as we had successfully done in the first system) all the data appears to have been sent, received and actually copied correctly to the Rx memory. The problem is that the SGDAM busy bit is not clearing.

Can anyone help me and give some direction of where to look ? The software engineer that I am working with has told me he is using exactly the same code as he used for the first system and he thinks has made the appropriate changes to the initialization code.

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Has the RUN bit in control register been cleared after completion of dma transfer?

    --- Quote Start ---

    The software engineer has told me he is using exactly the same code as he used for the first system

    --- Quote End ---

    I heard myself this statement a million times... and I usually answer asserting the same for hw side :D
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Cris72,

    Thanks for getting back to me so quickly.

    The Run BIT is still set -we still read a value of 0x85 from the Control Field inside the Descriptor.

    This is quite an annoying issue as I copied the exact connections as I had made with the 1st CPU (and double checked it). I am at a bit of a loss what to do next other than look into the RTL viewer and start poking around at signals - but this seems a little bit of daunting task since I know very little about the system and how it functions !

    --- Quote Start ---

    I heard myself this statement a million times... and I usually answer asserting the same for hw side :D

    --- Quote End ---

    I have a similar running joke here that at the start or end of most Hardware software interface "meetings" the blame is always attributed to the :wacko:other side:wacko: :p
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- Quote Start ---

    The Run BIT is still set -we still read a value of 0x85 from the Control Field inside the Descriptor.

    --- Quote End ---

    This means the descriptor has the OWNED_BY_HW bit set (0x80).

    I think the last descriptor in your chain must have its OWNED_BY_HW bit cleared.

    Otherwise the dma core is supposed to continue processing and would not release the busy flag.

    Are you using a true descriptor chain or are you testing with a single one? If the latter, then the error is indeed on sw side (LOL :cool:) because OWNED_BY_HW should have been programmed to zero. If instead the transfer stops on the very first descriptor of the chain, then it's likely 'you' have a problem :oops:
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi,

    We use a descriptor chain of length 2. the first descriptor command field is set to 0x85, the second one is set to 0. In addition to not seeing the busy cleared we also don't see the 0x85 in the first descriptor cleared. The packet is actually sent but without the end of packet signal. This in turn causes the receiver to get the data but not realize that it's complete.

    Thanks
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    We are not using infinite length frame.

    We still have not found a solution to our problem. Does anyone have any more ideas ?

    I have attached a copy of a file that shows the output of the program that is running with our system. It also includes a printout of the descriptors.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Things are a little different. We renamed the DMA related components (TSE, SGDMA. memory associated with DMA) within our SOPC system.

    Now when start a DMA and read back the DMA status we get an 0x18. That is BUSY + CHAIN_COMPLETED. The 0x85 in the descriptor control byte is still there.

    When DMA works , the 0x10 in the DMA status turns into a 0xC (DESCRIPTOR_COMPLETED + CHAIN_COMPLETED. It should be impossible to get a CHAIN_COMPLETED without an accompanying DECRIPTOR_COMPLETED or to get a CHAIN_COMPLETED without clearing the busy or the descriptor control byte but we're managing both.