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.

DMA RAM to RAM transfer does not work

Other Parts Discussed in Thread: RM57L843, HALCOGEN

Hi all,

I run into a problem that MibSPI RAM to L2 RAM DMA does not work. Thus, I am trying a simple case which transfers A array to B array.The MCU is RM57L843. I am stuck at here for days. Any help appreciated.

Here is a simple try out for DMA experiment.

I am expecting when set the software trigger to channel 1, then data should be transferred from array a to array b. However, there is no such thing happened. The array B keeps untouched.

     uint16 a[22],b[22];
     int i = 0;

    // assign values to array A
     for (i = 0 ; i < 22; i ++ )
     {
         a[i] = i;
     }


     // Initialize DMA Channel 1
     g_dmaCTRLPKT1.SADD      = (uint32)a;    /* source address             */
     g_dmaCTRLPKT1.DADD      = (uint32)b;    /* destination  address       */
     g_dmaCTRLPKT1.CHCTRL    = 0;                 /* channel control            */
     g_dmaCTRLPKT1.FRCNT     = 1;                 /* frame count                */
     g_dmaCTRLPKT1.ELCNT     = 22;                  /* element count              */
     g_dmaCTRLPKT1.ELDOFFSET = 0;                 /* element destination offset */
     g_dmaCTRLPKT1.ELSOFFSET = 0;                 /* element source offset */
     g_dmaCTRLPKT1.FRDOFFSET = 0;                 /* frame destination offset   */
     g_dmaCTRLPKT1.FRSOFFSET = 0;                 /* frame source offset   */
     g_dmaCTRLPKT1.PORTASGN  = PORTA_READ_PORTA_WRITE;
     g_dmaCTRLPKT1.RDSIZE    = ACCESS_16_BIT;     /* read size                  */
     g_dmaCTRLPKT1.WRSIZE    = ACCESS_16_BIT;     /* write size                 */
     g_dmaCTRLPKT1.TTYPE     = FRAME_TRANSFER ;   /* transfer type              */
     g_dmaCTRLPKT1.ADDMODERD = ADDR_INC1;         /* address mode read          */
     g_dmaCTRLPKT1.ADDMODEWR = ADDR_INC1;       /* address mode write         */
     g_dmaCTRLPKT1.AUTOINIT  = AUTOINIT_OFF;       /* autoinit                   */

     dmaREG->GCTRL |= 0x00000001U; /* DMA software reset */


     dmaSetCtrlPacket(DMA_CH1,g_dmaCTRLPKT1);

     dmaEnable();

while(1)
{
    dmaSetChEnable(DMA_CH1, DMA_SW); // trigger DMA transfer
    Delay(400000);
}

Here shows the result, which B does not get anything from A.

I think the configuration part is correct as there the Channel configuration is set.

The part I do not understand is the CSADDR register. I should be the current source address. However, I have no idea why the number is not even close to expected source address.

For more in detail, I paste the register values after Delay(400000);

  • This is a really bad situation.

    I have put the DMA module to debug mode. It does response as expected.

    It seems that the DMA state machine does incrementally "read" and "write"  based on the value of "PrtAChnSrcAddr" and "PrtAChnDstAddr". The transfer count is also correct, based on the value in "PrtAChnTrCnt ".

    PS: The documentation of above three registered is totally a mass. The names are inconsistent. Descriptions are inconsistent. The name s are also inconsistent with the HalCogen code. Basically, there is no consistency at all. Such disappointed.  The RM57 doc is no doubt substandard even it is still not finalized. I bet the correct list, if there were corrections,  will be no shorter than technical reference itself.

    However, no matter how I tried, there is no data transferred. Weird enough, there is no sign of errors in any registers. I conclude that the DMA module does not have any physical connections to the rest of MCU.  Be specific, the port A and port B are not implemented. Or, the silicon is misprocessed.  It is understandable to have serious bugs on unqualified product.


    There is very little documentation about the new Cortex-R5F (TMS570LC/RM57) series.  I have to move on to another platform.

     

  • Yuncheng,

    Is this the same issue as the one posted here e2e.ti.com/.../412878
    If so I'll close this out since it looks like the other thread has more progress on the issue.
  • Yes, please close this thread.