Can DMA of slave SPI read transfer terminate on transfer complete

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

Can DMA of slave SPI read transfer terminate on transfer complete

Jump to solution
2,471 Views
freddy_ben-zeev
Contributor IV

I’m using s32k148 and configured an spi slave channel with dma transfer. It looks like I have to know in advance the length of data to be received. If I try to set it to receive some max buffer size value and the spi master sends less data, the slave continues the dma read to the full count I specified filling the rest of the buffer with garbage (in other words – it continues to read even after the CS signal from the master went inactive). Is this a bug or a feature? Or did I miss something?

Freddy

Tags (2)
0 Kudos
1 Solution
1,997 Views
razva_tilimpea
NXP Employee
NXP Employee

Hi Freddy,

Yes, the hardware was designed in a different way, but I think you can do a workaround.

Can you connect CS to an GPIO and configure it to detect inactive state and to generate interrupt. In interrupt handler you can call abort transfer function for lpspi.

Best regards,

Razvan

View solution in original post

0 Kudos
9 Replies
1,997 Views
vanaua
Contributor I

hi! have you solved your problem? Similarly, I had a problem with using spi's dma mode for host and slave communication. I did not use the SDK, but directly read and write registers when programming. In the following code,  I tried to use s32k116 that was set as a slave device to  communicate with the external spi host device,however, While the host  keeps sending 128 bytes of data, the slave DmaA receive interrupt could not be triggered,so I could not receive or send any data. could you help me find out where the problem is? Thank you very much.

0 Kudos
1,997 Views
razva_tilimpea
NXP Employee
NXP Employee

Hi Freddy,

Based on your comments I suppose that you are using SDK drivers. They are designed to specifies the length of the buffers when transfer is started. 

As far as I know the DMA shouldn't read dummy thinks because  when RX fifo is empty due to the lack of data  from master side LPSPI doesn't send any request to DMA channel.

Can you show me how do you use SDK drivers in your application?

Razvan 

0 Kudos
1,997 Views
freddy_ben-zeev
Contributor IV

Thanks Razvan.

Good news and bad news... You're right (and I was mistaken) that if the master sends less data than the slave expects the slave will not receive garbage as I wrote in my original question (I don't know why I thought so...). But the bad news (for me) - it will continue to wait for data until it times out or forever in my case. It does not have the option to terminate the DMA at the end of one SPI transaction (when CS goes inactive) which is what I'd like to do. This does not seem to be SDK issue but h/w issue.

Freddy

0 Kudos
1,998 Views
razva_tilimpea
NXP Employee
NXP Employee

Hi Freddy,

Yes, the hardware was designed in a different way, but I think you can do a workaround.

Can you connect CS to an GPIO and configure it to detect inactive state and to generate interrupt. In interrupt handler you can call abort transfer function for lpspi.

Best regards,

Razvan

0 Kudos
1,997 Views
freddy_ben-zeev
Contributor IV

This is what I thought. Thanks.

0 Kudos
1,997 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Freddy Ben-Zeev

DMA request is triggered by the Receive Data Flag, and this flag is set only when the level in RXWATER has been reached, if there isn't clock by the master, then the fifo should not be filled and then it shouldn't trigger the DMA transfer. How do you configure the LPSPI FIFO? and what is the trigger of your DMA? could you verify that the Receive data flag is set only once?


Have a great day,
TIC

-------------------------------------------------------------------------------
- If this post answers your question, please click the "Mark Correct" button. Thank you!

-------------------------------------------------------------------------------

0 Kudos
1,997 Views
freddy_ben-zeev
Contributor IV

RXWATER is still count based. SPI transfer ends when the CS signal goes inactive - shouldn't there be an option to stop the transfer at this point?
At this point I don't program those flags directly - I use the SDK from NXP - butmy impression is that the limitation in this case is in the h/w design.

0 Kudos
1,997 Views
jorge_a_vazquez
NXP Employee
NXP Employee

Hi Freddy Ben-Zeev

Receive Data Flag should not be set if you have not received all the data in the fifo buffer, and the module will not be enabled if the CS is inactive (even if there is a clock in the line).

I recommend you to check the example code of the SDK, there is a lpspi_dma example code that uses master and slave, it could help you in your implementation.


Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
-------------------------------------------------------------------------------

0 Kudos
1,997 Views
freddy_ben-zeev
Contributor IV

I don't think you understood what I was asking...
Normally (or at least in many cases) an SPI transaction starts with CS going active and terminates with it going inactive - controlled by the master. When using DMA to read the received data on the slave it would be nice if the DMA can terminate when this happens. Unfortunately it seem that the slave in this MCU assumes that "all the data" is always the count of bytes programmed into the DMA controller. In many cases that I worked with in the past "all the data" meant the data from CS going active to CS going inactive - because the slave SPI did not know how many bytes will be in this range. Some DMA controllers I worked could use the CS going inactive as a terminating signal. Here it does not seem to be possible.

This gives me the two alternatives (which I don't like) to have a higher level protocol telling the SPI slave how many bytes to expect, or receiving always some maximum number of bytes and embed in the data the actual count. Both options are somewhat of a "hack"...

Freddy

0 Kudos