LPSPI eDMA Continuous Transfer on i.MXRT1176 (M4)

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

LPSPI eDMA Continuous Transfer on i.MXRT1176 (M4)

1,197 Views
svoulaz_ik
Contributor III

Hello,
I am running some performance test using LPSPI on i.MXRT1176, so I started by checking the code samples provided in SDK 2.14.0. The problem is, continuous transfer is not working as expected - and I suspect an issue in SDK code or an undocumented behavior in the IP.

I am using code sample lpspi_edma_b2b_transfer_master_cm4 (on the EVK) and I noticed that only the very first transfer is executed in continuous mode - i.e., CS not deasserted ad every frame boundary. For any following transfer, CS toggles at every frame boundary.

It has to be noted that TCR.CONT is correctly set to 1 in LPSPI_MasterTransferPrepareEDMALite (since kLPSPI_MasterPcsContinuous flag is specified), but it is (automatically?) reset to 0 after the very first transfer is executed - and any further transfer will work in non-continuous mode. So far, I found no evidence of TCR.CONT being expressly cleared in the code.

Changing the library code to restore TCR.CONT at every transfer seems to work, just by adding the following line after line 449 in fsl_lpspi_edma.c  ( LPSPI_MasterTransferEDMALite function):

    base->TCR = (base->TCR & ~LPSPI_TCR_CONT_MASK) | LPSPI_TCR_CONT(1);
 

However, I would like to understand why TCR.CONT is reset and have confirmed whether this modification is safe or not.

Best regards,
Stefano

0 Kudos
Reply
4 Replies

1,115 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

There is one issue with the LPSPI IP where it is needed to clear TCR.CONT field after transferring bytes to avoid issues in the communication.|
More details here: Solved: RT1050 LPSPI last bit not completing in continuous... - NXP Community

Best regards,
Omar

0 Kudos
Reply

1,040 Views
svoulaz_ik
Contributor III

Hello Omar,
thank you for the reply. This is not however the problem I am facing. In my case, TCR.CONT is apparently being reset after each transfer, so it must be re-set at the beginning of each transfer to keep the behavior consistent. Easy and straightforward to check using the mentioned example lpspi_edma_b2b_transfer_master_cm4: only the very first transfer is executed in continuous mode - i.e., CS not deasserted ad every frame boundary. For any following transfer, CS toggles at every frame boundary.

Best regards,
Stefano

0 Kudos
Reply

1,188 Views
svoulaz_ik
Contributor III

In this specific case, the line of code has been added to LPSPI_MasterTransferEDMALite , the function that actually starts the transfer. No additional frame should be added, but I share your doubt. That's why I would like NXP tech support to confirm and possibly fix this behavior - my test refers to sample code in the SDK, running on NXP evaluation board.

 

0 Kudos
Reply

1,189 Views
ramprakash12
Contributor II

Based on the context provided, it seems that the TCR.CONT bit is being reset after the first transfer, which is causing the CS to toggle at every frame boundary. This is likely an undocumented behavior of the LPSPI eDMA Continuous Transfer on i.MXRT1176 (M4).

As for the modification you made to the library code, it appears to be a workaround for this issue. However, it's important to note that writing to the TCR register inserts a new frame during a continuous transfer. In this case, TCR is not an ordinary register. Instead, it should be viewed as the entry to send control command.

Here is the code snippet you provided for reference:

 base->TCR = (base->TCR & ~LPSPI_TCR_CONT_MASK) | LPSPI_TCR_CONT(1); 

This line of code is setting the TCR.CONT bit to 1 at every transfer, which should keep the PCS asserted between frames. However, without more information about the rest of your code and the specific behavior of the i.MXRT1176 (M4), it's difficult to confirm whether this modification is safe or not. It's recommended to thoroughly test this modification under various scenarios to ensure it doesn't introduce any unexpected behavior.

0 Kudos
Reply