LPSPI not working correctly on iMX RT1062

[DavidVos]

Hi,

I've been working with the iMX RT1062 OEM for a while now trying to write an LPSPI driver but have encountered some problems. I have been working with the example projects in the MCUxpresso SDK.

The specific example project I'm working with is cmsis_lpspi_edma_b2b. The readout from master when running the project is:

LPSPI CMSIS driver board to board edma example.
This example use one board as master and another as slave.
Master and slave uses EDMA way. Slave should start first. 
Please make sure you make the correct line connection. Basically, the connection is: 
LPSPI_master -- LPSPI_slave 
CLK -- CLK 
PCS -- PCS 
SOUT -- SIN 
SIN -- SOUT 
GND -- GND

Master transmit:

01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
This is LPSPI_MasterSignalEvent_t
Master transmit data to slave has completed!
This is LPSPI_MasterSignalEvent_t
Master receive data from slave has completed!

Error occurred in LPSPI transfer !

Input any char to run again

 And from slave:

LPSPI CMSIS driver board to board edma example.

Slave example is running...
This is LPSPI_SlaveSignalEvent_t
Slave receive data from master has completed!
This is LPSPI_SlaveSignalEvent_t
Slave transmit data to master has completed!

Slave receive:
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40

Slave example is running...

As you can see the values sent and the values received match up, however the master still reports that the slave did not send the same values back. When rerunning the program and letting the master print out what the slave sends back it printed this:

Master received:

FF 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F

This was the printout when rerunning the code multiple times and letting master only print out what it sent and then received from the slave.

Master transmit:

01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40
This is LPSPI_MasterSignalEvent_t
Master transmit data to slave has completed!
This is LPSPI_MasterSignalEvent_t
Master receive data from slave has completed!

Error occurred in LPSPI transfer !

Master received:

FF 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F

Input any char to run again

Master transmit:

02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11
12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21
22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41
This is LPSPI_MasterSignalEvent_t
Master transmit data to slave has completed!
This is LPSPI_MasterSignalEvent_t
Master receive data from slave has completed!

Error occurred in LPSPI transfer !

Master received:

FF 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20
21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30
31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40

Input any char to run again

Master transmit:

03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12
13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22
23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32
33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42
This is LPSPI_MasterSignalEvent_t
Master transmit data to slave has completed!
This is LPSPI_MasterSignalEvent_t
Master receive data from slave has completed!

Error occurred in LPSPI transfer !

Master received:

FF 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11
12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21
22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31
32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41

Input any char to run again

 As you can see the first byte sent back by the slave is always FF. I am wondering what may be the cause of this as I can find no code in the example project which should lead to this behaviour.

Thank you for your time.

[mjbcswitzerland]

Hi

Receiving an unexpected value at the start of the test suggests that the master's Rx eDMA was triggered too early.

Make sure that there is no pending trigger when the test starts by ensuring that FIFOs have been flushed and that status register values are reset (which may remain ending from previous activity).

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

[DavidVos]

Hi @mjbcswitzerland ,

Thank you for your reaction. I have tried to insert the following two lines before the transaction as to flush the FIFO and clear the status flags.

LPSPI_FlushFifo(LPSPI1, true, true);
LPSPI_ClearStatusFlags(LPSPI1, kLPSPI_AllStatusFlag); 

But this has not solved the incorrect behaviour. Is there another method that I need to use to do this when using eDMA?

Best Regards,

David Vos

[mjbcswitzerland]

David

Another possibility is that the master's eDMA trigger for the LPSPI reception is being taken from its Tx ready signal and not Rx ready. This would allow optimal transmission rate but trigger the reception transfer too early.

There are two DMA MUX possibilities - LPSPIx Rx Fifo and LPSPIx Tx Fifo so make sure that the two eDMA channels are not both using the Tx Fifo trigger.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

[DavidVos]

@mjbcswitzerland 

Hi, 

Once again thanks for the reply. I added the following code before the transaction:

 DMAMUX_SetSource(DMAMUX, 1U, kDmaRequestMuxLPSPI1Rx);
DMAMUX_EnableChannel(DMAMUX, 1U);

However I still receive the same behaviour. I have noticed a few oddities while playing around with the various lpspi example projects. I have noticed:

• Slave needs to use eDMA, otherwise the slave will get stuck in the isTransferCompleted loop for some reason
• When letting the slave use the  eDMA CMSIS driver and the Master the CMSIS driver without eDMA I get the behaviour described in the first post
• Same behaviour occurs when testing with non-CMSIS example project (including that non eDMA slaves get stuck in a loop)

The more I work with this project the more flaky the behaviour seems to me. Any suggestions on what is to blame for this behaviour would be greatly appreciated. Thank you for your time.

Regards,

[Alexis_A]

Hello @DavidVos,

Can you let me know which device are you using as a slave? Also, have you tried looking at the memory after the last position to check if the array is shifted?

Best Regards,

Alexis Andalon

[DavidVos]

Hi @Alexis_A ,

The slave device is the same as the master, namely the iMX RT1062 (https://www.embeddedartists.com/products/imx-rt1062-developers-kit/). I have checked the memory position after the array and it is not shifted. There seem to be 2 bugs as far as I can tell.

1) If slave does not have DMA enabled the callback is not called after it sends information back meaning it gets stuck in an infinite loop thinking the transfer is not completed.

2) The first byte of the transmission from the slave is never correct according to the master. It is either FF or 00 (almost always FF though).

I don't know if this is one big bug on the slave side (the first byte transmitted is actually faulty). Or one small bug on the slave side and one small bug on the master side. Either way I'm completely clueless as to why the slave does not call it's callback after sending if DMA is not enabled.

Thanks for your time.
Regards,

David 

EDIT: I have been playing around with an oscilloscope and I found out that the fault is wholly the slaves (The first byte transmitted is faulty). I have no idea why this behaviour occurs but I probably won't invest a lot of time investigating it as I will use the iMX RT1062 only as master. Any suggestions as to why this behaviour occurs are still greatly appreciated though.

[Alexis_A]

Hello @DavidVos,

Can you let me know which SDK are you using?

Could you try using the Non-CMSIS drivers to check if this behavior is also present?

Best Regards,

Alexis Andalon

[DavidVos]

Hi @Alexis_A ,

The SDK that I'm using is 2.8.2.

I have tested the non-CMSIS drivers. This behaviour is not present in the interrupt example, but it is present in the eDMA example. Which leads me to believe that @mjbcswitzerland is right in his assertion that the problem is caused by the master's Rx eDMA being triggered too early. I have tried to insert the following two lines before the transaction.

LPSPI_FlushFifo(LPSPI1, true, true);
LPSPI_ClearStatusFlags(LPSPI1, kLPSPI_AllStatusFlag); 

But this has not solved the incorrect behaviour.

Best Regards,

David Vos