RT1064 - apparent conflict between edma receive on lpuart4 and lpspi3

[tkobet]

We are running the lpuart_edma_transfer example, modified for our custom hardware.  Data is received at 115200 bps on LPUART4, and a subset of that data is output to LPUART3.  This works fine, but if I configure lpspi3 to test another peripheral, the lpuart edma receive callback is no longer invoked.  If I pause the code in the debugger, the receive buffer has 4 bytes in it, and they look to be from the incoming data stream.

The receive buffer is configured to receive 35 bytes, so the callback is never invoked.  I tried changing the transfer to take 3 bytes instead of 35, but then the callback is only invoked one time.

If I comment out the SPI transactions on lpsi3, edma reception works.  The test does not include doing SPI transfers while serial data is being received.  lpspi3 is initialized, some blocking transfers are performed, then the edma serial transfers are initiated.

The same thing happens if lpuart1 is used for data reception.

Looking for clues as to how lpspi3 blocking transfers can walk on lpuart edma reception.

[tkobet]

Sometime there are functions that inside deactivates interruptions  explaining why the DMA callback was not called again. 

Did this idea pan out?  This is still an issue for us.  Wondering if using eDMA on the lpSPI transactions might help.

[tkobet]

Would changing the SPI transactions to use eDMA be a potential solution?

[Omar_Anguiano]

Could you give more details about the LPSPI implementation? How you configured? Wich pins you used? What are the functions implemented? Sometime there are functions that inside deactivates interruptions  explaining why the DMA callback was not called again. 

Best regards,
Omar

[tkobet]

The SPI port is lpspi3 with these pin assignments:

CS0 - H12

SDI - H11

SDO - G12

CLK - J14

This is the init code:

const lpspi_master_config_t LPSPI3_config = {
  .baudRate = 10000000UL,
  .bitsPerFrame = 8UL,
  .cpol = kLPSPI_ClockPolarityActiveHigh,
  .cpha = kLPSPI_ClockPhaseFirstEdge,
  .direction = kLPSPI_MsbFirst,
  .pcsToSckDelayInNanoSec = 1000UL,
  .lastSckToPcsDelayInNanoSec = 1000UL,
  .betweenTransferDelayInNanoSec = 1000UL,
  .whichPcs = kLPSPI_Pcs0,
  .pcsActiveHighOrLow = kLPSPI_PcsActiveLow,
  .pinCfg = kLPSPI_SdiInSdoOut,
  .pcsFunc = kLPSPI_PcsAsCs,
  .dataOutConfig = kLpspiDataOutRetained,
  .enableInputDelay = false
};

static void LPSPI3_init(void) {
  LPSPI_MasterInit(LPSPI3_PERIPHERAL, &LPSPI3_config, 105600000);
}

SPI transactions follow this pattern (data is read a few times, but write transactions are used predominantly):

   masterTxData[0] = 0x00;
   masterTxData[1] = 0x00;
   masterTxData[2] = 0x00;

   masterXfer.txData   = masterTxData;
   masterXfer.rxData   = NULL;
   masterXfer.dataSize = 3;
   masterXfer.configFlags = kLPSPI_MasterPcs0 | kLPSPI_MasterPcsContinuous;  // | kLPSPI_MasterByteSwap;

   result = LPSPI_MasterTransferBlocking(LPSPI3, &masterXfer);

Let me know if further information is needed.