Is there a way to respond to an SPI master request in the next transfer on the LPC55S28

[WilliamW]

In SPI it is common for the master to make a request and then on the following transaction to expect a response to the request.  I am attempting to do this with an LPC55S28 running at 150MHz with the master transferring at about 156000bps.  I have the kSPI_RxLvlIrq interrupt enabled and I am handling it with a FLEXCOMM8_IRQHandler function.  I have pulled out the necessary code to do the transfer without using fsl functions.  No matter how quickly I write to the SPI I can't get the slave's response to the master's request to transfer in the next transaction.  Instead it transfers in the transaction after that.  The master device cannot be changed to expect a dummy transaction.  I have reviewed the  SPI example code and note that it does not show a transaction where the slave responds immediately to a request from the master as I am attempting to do.

Is there something else I can do to get the SPI slave to response to the master's request in the next transaction?

[frank_m]

> I have reviewed the  SPI example code and note that it does not show a transaction where the slave responds immediately to a request from the master as I am attempting to do.

Because this is not possible, and not the way how SPI works.

SPI is a simple synchronous protocol involving shift registers. While the master is clocking out it's shift register contents (via MOSI), the contents of the slave's shift register are clocked in at the same time (MISO). 

The slave device cannot answer to an request that it has not yet received.

In case of a request/response protocol, the master must discard the MISO data received during request transfer. Only a follow-up transfer can contain the answer. How this is to be done depends on the slave device. Check the regarding datasheet.

[WilliamW]

Hi Frank,

I think that my use of the word "immediately" in the sentence that you quoted was confusing.  What I meant was in the next byte or word to be transferred.  Here is an example:  On the master I begin the process of transferring two bytes.  The first byte contains a request and the second byte will contain the response from the slave.  The slave sees the request after the first byte is transferred and quickly prepares the response.  When the second byte is transferred by the master, the slave controls his data line to provide the response.  

I've successfully done this on other processors by setting the next output value before the master begins transferring the second byte (or 16-bit word in my case).  It seems that no matter now early in the interrupt handler (for RX not empty)  I write the response, the processor does not use the value provided.  It seems as though the processor is loading the next byte to be sent before the interrupt is called.

Is there some way to do what I am describing or will I need to bit bang the data to implement this feature?

[frank_m]

> On the master I begin the process of transferring two bytes.  The first byte contains a request and the second byte will contain the response from the slave.  The slave sees the request after the first byte is transferred and quickly prepares the response.  When the second byte is transferred by the master, the slave controls his data line to provide the response.  

Well, yes. It was slightly confusing. But what do you mean, for example, with "transferring two bytes" ?  Two transfers of 8 bit, or one transfer of 16 bit ? The SPI interface is not really standardized, and allows different transfer sizes, even "odd" ones.

For your problem, you need to look at the slave's datasheet. I suppose there is a detailed description of such a transfer. Are there auxiliary signal transitions involved, like /SS ? Are there timing constraints mentioned ?

It would be helpful to specifiy the slave device we are talking about.

[WilliamW]

Hi Frank,

I've written the code on both devices I am working with, so who "I" am becomes confusing at times.  As to this problem, the LPC55S28 is the slave and the master is a device we call the 645.  I tried to simplify the  description of the transaction referring to a byte but the transfer is in 16-bit words.  The LPC55S28 is emulating a removable EEPROM device called a Datakey.  You can find the interface specification for it here: https://datakey.com/products/lcs-series

The 645 performs two 16-bit transfers while the chip select is active with a clock that is running at about 156kHz.  The first 16-bit transfer (on MOSI) contains a command code (indicating that we want to read a 16-bit word) and the address of the EEPROM data that is desired.  The second 16-bit transfer occurs about 5us after the first.  For that transfer the 645 expects that the 16-bits of data will be set by the LPC55S28 slave (on MISO).

On a previous implementation that emulated the Datakey device using a PIC18 as a slave, I was able to receive the command/address and set the outgoing data for the SPI feature to the data at that address before the next transaction occurred, about 5us later.  When the 645 performed the second transfer, the PIC18 used the data that was just set for the SPI output to provide the 645 with the data at the given address.

I am attempting to do the same thing with the LPC55S28.  I get the interrupt indicating that the first 16-bit value has been received, and I write the desired outgoing value to the SPI buffer.  Using an oscilloscope and GPIO line that I am using as a test point I can see that the outgoing value written to the SPI buffer has been written even before the last clock cycle of the first 16-bit transfer has been completed.  However, when the 645 performs the second 16-bit transfer the data set by the LPC55S28 is not the outgoing value just placed in the SPI buffer.

The outgoing data does show on the transfer after that.  But obviously, that won't work to emulate the Datakey device.  I've looked through the user manual (UM11126) but haven't been able to find anything that talks about the ability to do what I am trying to do or any settings that might be changed to affect how it works.

[frank_m]

Without going too deep into this issue ...

> The LPC55S28 is emulating a removable EEPROM device called a Datakey.

Can you be sure your emulation is fully correct ? A proper test would be to attach the emulation to a board/code that previously worked fine with the actual device.

> On a previous implementation that emulated the Datakey device using a PIC18 as a slave, I was able to receive the command/address and set the outgoing data for the SPI feature to the data at that address before the next transaction occurred, about 5us later.

While I guess the PIC18 supports SPI transfer sizes above 8 bit (e.g. 16 bit), this is still a 8-bit MCU.

The rest of the description sounds like the transmission logic of the (slave) LPC55S28 does not behave as expected. I must admit I have no experience with LPC55Sxx devices, just assuming the same SPI-IP like on other LPC controllers is used.

What I would do - make scope or logic analyzer recording of all involved lines (Clk, MISO, MOSI, SS) on both slaves (or better, one on an actual 645), and compare both.

One pitfall of SPI is it's high configurability, especially clock polarity and trigger edge. Perhaps there is a mismatch in those settings.