SPI response arrives later than expected

[CanolCael]

Hello, we have a project which uses LPC55S28 MCU. We are trying to do an SPI communication where LPC55S28 is the slave and a custom hardware is master.

The communication is like this: total communication will last 2 bytes. Master sends 1 byte. Then slave will respond with 1 byte.

We are using the Flexcomm 8 which is the high speed SPI.

My SPI setup function looks like this:

void setup_spi() {
    spi_slave_config_t slave_config;
    SPI_SlaveGetDefaultConfig(&slave_config);
    SPI_SlaveInit(SPI8, &slave_config);

    NVIC_SetPriority(SPI_SLAVE_IRQ, 0U);

    EnableIRQ(SPI_SLAVE_IRQ);
    SPI_EnableInterrupts(SPI8, kSPI_RxLvlIrq);
}

This sets up so that we enter the interrupt every 1 byte.

And my interrupt function looks like this:

void SPI_SLAVE_IRQHandler() {
    if (!(SPI_GetStatusFlags(SPI8) & kSPI_RxNotEmptyFlag)) {
        return;
    }

    // Currently I am not doing anything with the incoming message.
    uint16_t message = (uint16_t)(SPI_ReadData(SPI8) & 0xFFFF);

    // This response will appear not 1 byte later, but 2 bytes later
    SPI_WriteData(SPI8, 0xAB, 0);

    SDK_ISR_EXIT_BARRIER;
}

The behavior I observe is different than what I expect: when I start a 2 bytes communication on master, I can observe that the interrupt is called 2 times, which is what I expect, but I read 0xFFFF from the slave. The next times I start another 2 bytes communication, I receive 0xABAB because the TX FIFO is already filled with two 0xAB bytes.

What I expect is to receive something like 0xFFAB. So half of the response would be empty, because slave still didn't get into the interrupt yet and TX FIFO is empty, but after receiving one byte, it goes into the interrupt, 0xAB is written to the TX FIFO, so that slave sends 0xAB when reading the second byte.

As a bonus, I started a 4 byte communication from master (by lowering chip select line for 4 bytes). I can see that the interrupt is entered 4 times. But the response I get is 0xFFFFABAB. Instead of 0xFFABFFAB.

It is as if SPI_WriteData is not fast enough. Or maybe one of my settings is not correct? What do you think is the problem here?

[Tom_VU]

Hi Alice,

My name is Tom, a colleague of Canol also working on this project. Our SPI protocol is based on the LPC55S28 receiving the first byte (and sending out a 0x00 byte during this time), but the 2nd byte that the LPC55S28 should sent is based on the value of the 1st received byte (this 1st byte is an address into a table and we need to send the table value back to the master side).

What we do in the interrupt routine triggered after receiving the 1st byte is write the table value in the TX FIFO. But we see that value only being clocked out as 3th byte to the master.

We think that the 2nd byte to transmit is already read from the TX FIFO just after the 8th clock edge on SCK. So at the moment we did not write in the TX FIFO yet because we have yet to process the RX interrupt.

Can you confirm that this is the way the SPI peripheral works? We couldn't find it in the manuals so far. We may need to adapt our protocol if we can't put the 2nd byte to transmit fast enough in the TX FIFO

Thank you

BR Tom and Canol

[WilliamW]

Were you able to figure out a solution to this problem?  I'm having the same problem.  I get the data from transaction 1 and try to write for transaction 2 but it doesn't show up until transaction 3.

[Alice_Yang]

Hello Tom and Canol,

Yes, you are right. 

Each time SPI communication is started up by Master, when Mater continuously send two bytes(at same time receive two bytes), for the 2nd one, as you said,  Slave is processing the RX interrupt, have not complete filling TX FIFO. 

BR

Alice

[Alice_Yang]

Hello,

SPI receive and send at the same time, so when the first byte SPI master received not the data send from SPI slave interrupt. You can put the SPI send function in main() function to test.

And please refer to the SPI interrupt demo under SDK.

BR

Alice