SSP in SPI slave mode: How to receive data without lag?

[lpcware]

Content originally posted in LPCWare by MindBender on Wed Jul 29 00:00:59 MST 2015
We are using SSP0 in SPI slave mode and I notice our SPI received data handling is lagging behind on actual bus activity. I'm suspecting the FIFO is the culprit, because the two interrupts firing on received data, RXRIS en RTRIS, fire with a delay: The first after fires 32 bit times after the first byte at best, and the second fires after half the FIFO size bytes have been received. Or am I misunderstanding something?

If I'm correct, this would mean that the LPC slave SPI interface in unable to respond a master's command within a single SPI transaction.

[M_H]

I am using SSP0 on the LPC4088 with SSP_FRAMEFORMAT_SPI and experiencing similar issues.

It appears the LPC4088 shifts a frame in/out of the FIFO whenever the chip select goes from the low state to the high state. 
I believe for SPI communication the chip select is normally held low for the duration of a transaction (multiple frames) but for some reason the LPC4088 instead uses the chip select to indicate the transmission of a single frame. 

I am using a Linux device as the master and ioctl to send SPI messages, looks like I might have to set up a new transmission for every frame.

Also, the interrupts offered by the SSP are not useful if I want to load a new transmission frame based on a received frame, normally for SPI peripherals you would expect to have an interrupt when a new frame has been received but the interrupts for the SSP lack this. Looks like I will instead have to use a GPIO interrupt on the chip select line (a long with the chip select line being toggled between every frame) to load the next transmission frame into the FIFO. 

[M_H]

After discussion with colleagues it appears the chip select behaviour actually depends on the values used for clock polarity and clock phase (bad chip design?).

Setting up the SSP with the clock phase bit (CPHA) set allows continuous data transfers to occur. 

The functions Chip_SSP_GetStatus, Chip_SSP_ReceiveFrame, and Chip_SSP_SendFrame can then be used to read the FIFO as data enters and write out new data immediately. 

[lpcware]

Content originally posted in LPCWare by MindBender on Wed Jul 29 04:51:24 MST 2015
The slave behaviour we need to implement on our LPC-based board is this:

      ___                                   ___
         \                                 /
SSEL      \                               /
           \_____________________________/

               ####   ####   ####   ####
Clk            ####   ####   ####   ####
      _________####___####___####___####______
      ______   ____   ____   ____   ____   ___
            \ /    \ /    \ /    \ /    \ /
MOSI      *  X cmd  X  *   X  *   X  *   X  *
      ______/ \____/ \____/ \____/ \____/ \___
      ______   ____   ____   ____   ____   ___
            \ /    \ /    \ /    \ /    \ /
MISO      *  X  *   X dat0 X dat1 X dat2 X  *
      ______/ \____/ \____/ \____/ \____/ \___

This is very much like many dumb SPI slaves, like sensors, behave. The command byte often is a register address combined with a read/write bit.

Can anybody please confirm (or deny) that this is possible with the LPC SSP peripheral?