K64 + KSDK1.3: EDMA DSPI slave behavior?

[scornelius]

Hi!

I've got am m2m K64 implementation running a DSPI slave using EDMA.

I can receive a packet of expected length every time.

Building on that, I was trying to receive a packet of unknown length into a buffer expecting the chip select to frame the message.

Since SPI is typically framed by the chip select, I expected an event when the master released the chip select.

What I'm seeing is that the DSPI_DRV_EdmaSlaveTransferBlocking(..) call does not return until it receives all the characters that "transferByteCount" request (or a timeout occurs).

It looks like the chip select is only gating the data shifted into the DSPI system. It's state is not being monitored.

So, my question is, is there anyway to terminate an transfer when the chip select is released?

Thanks,

  Steve

[mdecandia]

Is this true also without using DMA?

Michele

[xiangjun_rong]

Hi, Steve,

Regarding your question, if you use the api function DSPI_DRV_EdmaSlaveTransferBlocking(..), as you said that the api function was blocked until the specified  time has elapsed or the specified datas have been transferred. Blocking means the OS gives up running the function and switch to the other task.

You can call the dspi_status_t DSPI_DRV_EdmaSlaveTransfer(), and use the DSPI_DRV_EdmaSlaveGetTransferStatus() to get the transferring status and the number of datas which have been transfered, then determine if you terminate the transfer or not. you can call the DSPI_DRV_EdmaSlaveAbortTransfer() to about the transferring.

Pls check the example directory:

D:\Freescale\KSDK_1.3.0\examples\twrk64f120m\driver_examples\dspi\dspi_edma_non_blocking\slave

BR

XiangJun Rong

[scornelius]

XiangJun,

Thank you for your response.

Some more system information I overlooked mentioning:

     1) We're using MQX, and soon will be forced into FreeRTOS with KSDK 2.0.

     2) It is our desire to run the DSPI at 1-10 MB.

I've been through all the examples, and the hardware reference manual (K64P144M120SF5RM.pdf, rev 2).

I'm aware of the polling method, but without putting a OS sleep between polls other tasks are blocked.
For that sleep, the OSs have a  5ms tick, which limits the sleep time.

Since our application is m2m, we're implementing a protocol similar to a SPI EEPROM for read and write access.

In our case, when generating a response sleeping for that long would miss the rest of the packet without causing the master to insert pauses between sections.

As to DSPI_DRV_EdmaSlaveGetTransferStatus(), that only returns byte count, and kStatus_DSPI_Busy or kStatus_DSPI_Success.

Nothing indicates the state of the chip select (PCS0/SS), or if it had been released.
Looking at the reference manual, chapter 50:

  Section 50.1.2 PCS0/SS—Peripheral Chip Select/Slave Select only states:

     "Slave mode: Slave Select (I)—Selects the module to receive data transmitted from an SPI master."
     There is no explanation, but from it's behavior it seems to only gate the clock to the shift register.

  Sections 50.3.5 and 50.3.6 do not seem to show a hardware indication of the current state of /SS.

I was hoping that someone more familiar with the hardware knew a work around.

Without hardware to test the state of the chip select, yes, polling might be the only way around it; watching for the byte count to stop increasing.

Thanks again,

Steve

[xiangjun_rong]

Hi, Steve,

Because the SPI module of K64 is set up in slave and DMA mode, the master SPI launches the data transfer, so the K64 core does not know whether the SPI data transfer is on-going or not. It seems that your question is if there is a way to know if the SPI  is transferring or not.

I think it is unstable to detect the SS pin logic directly by GPIO, because the SS pin is High during interval between two SPI data transfer.

This is my ideas:

1)connect the SS pin of SPI to FTM_CLKIN, and have the FTM as a free-running counter, you can launch a task, in the task, checking the FTM counter, if the FTM counter is the same, you know that the SPI transfer is idle.

2)this is pure software solution. you can  use no-blocking SPI data transfer with DMA, launch a task, in the task, checking the if the returned Byte count by  DSPI_DRV_EdmaSlaveGetTransferStatus() is the same by two consecutive reading,  if the returned byte count is the same, you know that the SPI transfer is idle.

this is the pseudo code:

task()

{

delay(xx);

newValue=read(); //FTM counter or Byte countif(newValue==oldValue) { SPI idle}

oldValue=newValue;

}

If I misunderstand you, sorry.

BR

XiangJun Rong

[scornelius]

XiangJun Rong,

Thanks again for the thought on my question. I agree, there ways to work around this.

If the board wasn't done I could add more hardware. Connect the SS to a GPIO and use the SS release to generate an interrupt.

I also agree that adding code, and altering the protocol, would work.
I've already added extra code to get the board running, using two exchanges: a header of known size, a pause and the remaining data.
I'm sending a header that includes a total length indicator, the host pauses, and then sends the rest of the packet.
Using that, the slave can determine the remaining byte count, and catch them after the pause.

My desire is to do a single fast exchange, but if the hardware cannot indicate the release of SS, it's all a work around in firmware.

So, to clarify, it's a hardware question:
  Is there indication from the SPI slave hardware that indicates when the SS is released?
From the documentation, it seems that the answer is a definitive no.
Often the documentation is incomplete, or located in other documents. So now I'm looking for conformation.

Thanks,

Steve

[xiangjun_rong]

Hi, Steve,

I do not think there is indication from the SPI slave hardware that indicates when the SS is released from SPI itself. But there is SPI_TCR register, which contains a counter that indicates the number of SPI transfers made. I think you can read the register in a fixed period so that you can know if the transfer is on-going or not. This is a workaround.

Hope it can help you.

BR

Xiangjun Rong

[scornelius]

Xiangjun Rong,

Thanks again. I was waiting to see if anyone else commented, but no luck.
You've confirmed that my initial observation is correct; the SPI slave hardware cannot detect the release of SS.
I'll assume that our understand of the documentation is correct, and move on.

Thanks again for your thoughts and efforts,

Steve