• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 432 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.

66AK2G12: DMA reading from L2 SRAM issue

Richard Hewitt
Prodigy 40 points
Part Number: 66AK2G12

I am bringing up a McASP interface on a new design and have successfully obtained correct Tx output data from the McASP when written by the C66 DSP under software control. Moving on, I wish to service the McASP by EDMA and I have got to the point where the DMA appears to be operating and Tx frame sync pulse are appearing (using burst mode), however the Tx data is apparently all-zeros. The DMA is reading from a simple memory array in C66 L2 SRAM and writing to the McASP via the DATA port. The EDMATC_ERRSTAT register is indicating a bus error and the EDMATC_ERRDET register indicates that this is associated with the read cycle. I have read that if the read fails then the DMA transfer will still progress but with zero data, which appears to agree with my observations.

My question is, what are the possible causes of the read failure as I am running out of ideas? I have considered memory protection and the DMA is configured to use Supervisor privilege in the OPT field, however I am uncertain if this is sufficient (I have not configured any other specific considerations in respect of the MPU - in fact I am not interested in memory protection at this time and would prefer that all masters have access to everything for the moment). 

  • 0
    TI__Guru* 84155 points
    Richard
    Are you using any software from TI ? I believe there are McASP examples in the SDK? I recommend referring to those to have a baseline configuration.

    If you are seeing read errors - can you share your PARAM programming for the McASP DMA - what is the source address (read address) and other param values?

    Regards
    Mukul
  • 0
    TI__Guru** 116170 points
    Richard,

    As Mukul mentioned the MCASP LLD driver that we provide in PRocessor SDK RTOS for this device supports EDMA based implementation. I would recommend that you start by setting up the Audio loopback example that we provide with the SDK. The MCASP LLD only expects users to create the handle to the EDMA driver and sets up the transfer based on the data format in which the input and output data need to be read/feed into MCASP FIFO.

    Please refer to the implementation and examples which are documented here:
    software-dl.ti.com/.../index_device_drv.html

    If you still wish to implement this by creating your own driver then you can check the EDMA setup after setting up TI driver and replicate this with your setup. The driver however always uses the MCASP FIFOs.

    Regards,
    Rahul
  • 0 in reply to Mukul Bhatnagar
    Prodigy 40 points

    Hi Mukul,

    Thanks for your response. We are using SYS/BIOS, however out of project necessity, the only other TI code resources being used are header files that define register names and locations however, I will take a look at the McASP examples in the SDK to see if they shed any light.

    The following is a code snippet that, I believe, provides the further information that you requested:

    UINT32 tx_options = 0x80001206; // (1000) Supervisor privilege, 3 bits reserved write as 0 |
    // (0000) Privilege ID 0 |
    // (0000) No intermediate chain, No transfer complete chain, No intermediate interrupt, No transfer complete interrupt |
    // (0000) Reserved write as 0, TCC bits 5 to 4 |
    // (0001) TCC bits 3 to 0 |
    // (0010) Normal (end) transfer completion, FIFO width 32-bit |
    // (0000) Reserved write as 0 |
    // (0110) Not static set, AB-sync, Static destination, Incrementing source


    m_edmacontroller.AddTCC( tx_options, m_txdma_timestamp_edmachannel);

    UINT32 tx_destination = (UINT32)m_serialport.GetTransmittRegisterAddress(); // This is MCASP_0_SLV: 0x21804000

    // Configure for using DAT port destination of McASP
    m_edmacontroller.ConfigureEntry( m_txdma_primary_param_idx,  // PaRAM entry index
                                                            tx_options,                                 // Channel options, OPT
                                                            tx_ping,                                      // DMA Source address (in L2 SRAM (0x008033B0))
                                                            sizeof(CQ15),                            // Number of data Bytes in each array
                                                            3,                                               // Number of arrays in each frame
                                                            tx_destination,                           // DMA destination address (0x21804000)
                                                            tx_fwd_jump,                             // Address offset (Bytes) between source arrays within each frame
                                                            0,                                               // Address offset (Bytes) between destination arrays within each frame
                                                            32*m_txdma_link_param_idx[1],     // Link address (Byte address offset within PaRAM of linked set)
                                                            0,                                               // Array count reload value (for A transfers only)
                                                            sizeof(CQ15),                            // Source address offset (Bytes) between frames (differs for A and AB transfers)
                                                            0,                                               // Destination address offset (Bytes) between frames (differs for A and AB transfers)
                                                            Transmitt_BlockSize );              // Number of frames within the transfer block.

  • 0 in reply to Richard Hewitt
    Prodigy 40 points

    This issue was finally resolved when a colleague indicated that the DMA must access the L2 SRAM via an alternative address space to that of the C66. This is briefly and (I would say) indirectly referenced in the memory map table in the 66AK2G1x TRM, however nowhere else in any documentation that I have read is this mentioned. I suggest that the documentation is enhanced to better draw attention to this issue for the non-processor "Masters" on the SoC (e.g. what is the definition of the term "Reserved" in the context of the memory map?).