• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 580 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.

TMS570LS1227: DMA working packets always read zero

Jonathon Smith1
Prodigy 70 points
Part Number: TMS570LS1227

As noted, I am working with a TMS570LS1227.  I am trying to implement a driver for DMA transfers.  One of the options that I would like to implement is to stop the DMA transfer or check the status of the transfer.  For example, if I were using DMA to buffer data received from a serial port terminal rather than using interrupts, I may want to periodically read data from the buffer and restart DMA transfer to the buffer.  In this case, I would need to know how much data is transferred.

The information needed to do this is contained in the DMA working control packet for the channel being used.  When I attempted to implement this feature, I noticed that the working control packets (at offset 0x800) always read zero.  I also noticed one line somewhere in the technical manual that states: "The last three fields compose working control packet and are only readable by the CPU."  Given the amount of detail provided for these registers in the manual and given that they are memory mapped, I am not exactly sure why they would be hidden from the application.  It also severely restricts the capability of the DMA controller.

Could someone tell me if these registers are actually hidden and, if so, is there anything that can be done to view their contents?

  • 0
    TI__Guru**** 197036 points

    Hello,

    Once the channel is arbitrated, the current source address, destination address and transfer count should be copied to their respective working images.

  • 0 in reply to QJ Wang
    Prodigy 70 points

    QJ Wang,

    Thank you for the quick reply.  Unfortunately, this is not what happens.  For example, I have a program that configures DMA to receive 10 characters using DMA channel 1.  I then send three characters ("xyz).  I verify that the characters have been transferred, which they are:

    However, when I read the corresponding channel register in the primary control packet starting at address FF80 0020, one can see that it has been configured properly:

    I also know that I am in mid-transfer.  However, the corresponding working control packet at FF80 0810 and any other register in the range only ever reads zero:

    If I attempt to read that address in the program and use it, then it also reads zero.

    Can you please advise why it reads zero even when we have confirmed that its in the middle of a transfer waiting for a DMA request?

    Thank you,
    Jonathon

  • 0 in reply to Jonathon Smith1
    TI__Guru**** 197036 points

    Hello Jonathon,

    Your configuration is to use transfer data from flash to SCI3_TD (0x19 frames, DMA channel 0), and from SCI3_RX to SRAM (0xA frames, DMA channel 1). How do you trigger the DMA channel 0 transfers (from flash to SCI_TD) to arbitrate out channel 1 (from RD to SRAM)? 

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Hi QJ Wang,

    Thanks for taking the time to follow up on this issue.  After investigating further, I found the issue was that I was only executing transfers on one channel at a time.  Each channel was completing transfer before beginning transfer on the other channel.  Originally, I thought that the working packets were always updated, but it appears that the working packets are only updated if another channel activates while a channel is in mid transfer.

    It was fairly complicated but I was able to come up with an algorithm that uses the primary packets, the active channel registers, the working packets and the flags to determine number of elements transferred.  Basically if the frame transfer flag is never set, then I assume zero.  If the block transfer complete is set, I assume that all elements are transferred.  Otherwise, I capture the active channel registers and attempt to validate the current addresses and remaining elements/frames against the primary packet.  I attempt this twice with DMA transfers temporarily paused just to make sure that I did not capture registers while they are being updated by the DMA controller.  If they are not a match, then I assume that the channel has been arbitrated and use the working packet instead.  It's a bit complicated, but has worked reliably so far.  It would be nice if the working packet was always brought up to date though.

    For others who may run into this problem, just be aware that the working packet is only updated if a channel is in the middle of a block transfer and another channel activates.

    Regards,

    Jonathon