eDMA channel works only once

[kyf]

Hello NXP team.

I'm trying to setup an eDMA channel to move data from BCTU Fifo1 to an other buffer. I've done the setup bellow but I eDMA channel works only once and then it seems to become unresponsive.

The hardware that I'm using is S32K3X4EVB-172Q.

I've tried:

After 1 eDMA successfull transfer I've deinit the eDMA with Dma_Ip_Deinit() and then re-initialize the channel but it seems that nothing changed. For this I have the options bellow:

      

With the eDMA channel I want to achieve this:

I've been trying for many days to make this thing work and I've tried many stuff that I haven't recorded in order to post them.

Questions:

1. In which mode should I set up my eDMA in order to achieve the above setup ?? Should I use normal transfer or scatter/gather mode ?

2. Do I have to initialize the channel after every request successful request ?

3. Is it possible to automate a transfer like the one that I describe above ? (No CPU use)

4. How can I use this configuration ? It is always disabled and I can't test it.

Kind regards,

kyf

[kyf]

Hello @PetrS

Base on your comment:

yes, there is Data Path submodule which includes internal data buffer, read chapter 14.3.2 eDMA basic data flow for more info.

I've found out that unless I disable the data cache memory or assign my destination buffer to a non-cachable memory section eDMA transfers data only once.

I was also initializing eDMA channel before Bctu_Ip_init() and I've found out later that Bctu_Ip_init() also initializes eDMA channel and it was messing up my configurations :-(.  Anyhow... I've fixed that by changing the order of the functions. 

Lastly I would like to know if I have to do any extra handling regarding the cache except from turning this off ? I'm asking because when I erased the destination or the source buffer manually (memset or forLoop) the behavior of eDMA transfers became even more weird.

I'm 100% sure that I haven't handled correctly something regarding eDMA in this case but I can not figure out what it is. I will run some tests also today and I will let you know about the results.

Kind regards,

kyf

[kyf]

@PetrSI have one last question before I start testing things again.

Does the eDMA move data from SourceBuffer into a local(dma) memory and after this it does all the read/writes ? Is there any temporary local memory ?

or it just coppies data from SourceBuffer address to DestinationBuffer ?

I did not copy the correct screenshot from my configurations, sorry. This is the updated one with the correct values:

(Destination buffer is bigger than 36 because I wanted to test the DMA)

Not sure why DMAMUX is setup when SW request is used for DMA channel.

I didn't know that there was not need for using DMAMUX. I've just copied it from the Dma_Ip example.

Kind regards,

kyf

[PetrS]

Hi,

yes, there is Data Path submodule which includes internal data buffer, read chapter 14.3.2 eDMA basic data flow for more info.

Also check chapter 14.4.5 Performing DMA transfers for examples with read write transfers explanation.

for you last config; it could work if you add below into transfer list
DMA_IP_CH_SET_MINORLOOP_EN_SRC_OFFSET, TRUE
DMA_IP_CH_SET_MINORLOOP_SIGNED_OFFSET, -48

BR, Petr

[kyf]

Hey @PetrS  !

How you can have 36 commands in BCTU list if there is just 16 LISTCHR registers, holding 32 commands. Do you modify list in runtime somehow?

I've thought the exact setup as you are suggesting bellow:

So assuming FIFO1 watermark is set to 11, meaning DMA request is generated upon 12 ADC results are stored into FIFO1, to read 3 times those 12 ADC results into buffer below setting can be used, I think

But as every complex mechanism it didn't work in my first attempt. So I've chosen to test and learn the eDMA peripheral by running the examples regarding Dma_IP for S32K344. In this example the program includes 3 setup, 0 setup is from config tool (normal transfer), 1 is also from config tool (scatter/gather transfer) and 2 is being configured via the FW.

I've tried to replicate moving 3 times the 12 uint32 Data into a buffer. In short:

1. I've setup a source_buffer[12] with uint32 size data and a destination_buffer[36].

2. Setup DMAMUX (MuX0 Always ON0 channel).

3. Enabled and setup the normal transfer mode. I've tried configuring an other project with the config tool (i had same results, as it should be)

 

4. Init the Dma_Ip and after this set Global and Transfer lists

5. I've used a loop that does those stuff bellow:

1. Dma_Ip_GetLogicChannelStatus(DMA_LOGIC_CH_2, &t_GetChannel2Status);
2. Dma_Ip_SetLogicChannelCommand(DMA_LOGIC_CH_2, DMA_IP_CH_SET_SOFTWARE_REQUEST);
3. Delay 500 ms with STM timer
4. Increment source buffer contents by 3. I do this because I've noticed that DMA runs only 1 time the minor/major loops and it never works again. So I'm increasing the buffer in order to see via the debugger if the updated data overwrites the destination_buffer's data

Questions:

1. Is this wrong ?
2. Isn't it possible to sent a forth software request and start the sequence again ? I'm asking because if I do this setup the dma does not work as expected :/.
3. Destination final address adjustment is applied after every 48 minor loops are finished and not after the last major loop finishes. Is this the correct behavior ?

Kind regards,

kyf

[PetrS]

Hi,

1) yes, it is wrong. To implement scenario in 3rd picture a Source Minor Loop Offset need to be enabled too. Moreover minor loop size does not correspond to the size of your buffers. Not sure why DMAMUX is setup when SW request is used for DMA channel.

2) if configured properly it is possible. Upon each SW request a MINORLOOP_SIZE bytes are transferred. SOURCE_TRANSFER_SIZE/ DESTINATION_TRANSFER_SIZE specifies width (in bytes) of DMA reads/writes and SOURCE_SIGNED_OFFSET/DESTINATION_SIGNED_OFFSET defines how many bytes source/destination address is changed upon each read/writes. So you need to config rest of TCD parameters to fulfill your needs.

3) destination and source last offset is applied after major loop finished

BR, Petr

[PetrS]

Hi,

How you can have 36 commands in BCTU list if there is just 16 LISTCHR registers, holding 32 commands. Do you modify list in runtime somehow?

for your questions...
1) normal transfer can be used
2) no, you do not to initialize channel upon each request.
3) yes, it is
4) "Store Destination Address" (SDA) is not needed here.

So assuming FIFO1 watermark is set to 11, meaning DMA request is generated upon 12 ADC results are stored into FIFO1, to read 3 times those 12 ADC results into buffer below setting can be used, I think

BR, Petr