KSDK eDMA edma_software_tcd_t allocation needs to be 'number plus 1'

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KSDK eDMA edma_software_tcd_t allocation needs to be 'number plus 1'

1,006 Views
marcohess
Contributor II

I found that while using the KSDK EDMA_DRV_ConfigLoopTransfer function, the memory block passed to that function to hold the transfer control descriptors edma_software_tcd_t need to be the number of descriptors indicated plus 1.

 

This is different from the @param documentation that states that the size needs to be period * sizeof( edma_software_tcd_t )

 

Also, the documentation states that the memory block needs to be aligned on a 32 byte boundary.

 

However, stepping through the EDMA_DRV_ConfigLoopTransfer function it appears that internally it expects the size to be size to be (period + 1) * sizeof( edma_software_tcd_t ).

 

It uses the STDC_ADDR macro to enforce the 32 byte address alignment at the cost of needing an extra 32 bytes allocated.

 

So my


     edma_software_tcd_t  edma_transfer_descriptors0[2] __attribute__((aligned (32)));

 

did not work for the 2 descriptors that I needed. It actually needed to allocated 3 descriptors:

 

     edma_software_tcd_t  edma_transfer_descriptors0[3] __attribute__((aligned (32)));


and when used it ends up using edma_transfer_descriptors0[1] and edma_transfer_descriptors0[2] while ignoring edma_transfer_descriptors0[0].

 

Just so you know...

Labels (1)
Tags (2)
1 Reply

521 Views
bosleymusic_com
Contributor IV

I don't know if this helps at all but did you try using malloc or memset at all? I needed 1 descriptor for my application on K22, and using malloc and memset I only needed to allocate the actual amount of memory necessary for the TCD.

But you are absolutely correct that the descriptor argument is offset by one - it expects tcd[n] + 1.


I'm not sure where you are getting (period + 1) * sizeof( edma_software_tcd_t ) for the size argument. In my application and from looking at examples, it appears size is the number of bytes in the data type used in your transfer. I pass in two for int16t with one 1 tcd structure. If you're using 32 bit data with your peripheral, then your algebra happens to work out, but I don't think that's the way it actually works. Check out the SAI (SND really) twr audio examples in KSDK and you'll see a good example of how they handle the size argument. It's purely based on the number of bits in each piece of data, at least for SAI, but I can't imagine that's not a generic feature of the EDMA.



0 Kudos