Transmission SPI in slave mode buffered ?

[GuillaumeDourne]

Hi,

I'm using a MC9HS12XEP100.

I want to receive and transmit some data on a SPI.

My SPI is in slave mode, 16bits mode with SS/.

When I receive one word, I want to transmit an other word.

There is no problem on the reception, but the transmission seems to be delayed, as there is a transmission buffer of 2 words.

Whereas the SPI2DR register is set to 0x1111 for exemple, the 2 first word transmitted are 0x000, and the third is 0x1111.

I want to transmit :

0x1111

0x2222

0x3333

0x4444

0x1111

0x2222

....

But in fact the transmission is :

0x0000

0x0000

0x1111

0x2222

0x3333

0x4444

0x1111

....

Is the 2 words transmission buffer  configurable. How can i deactivate it, or how can I force this value ?

My interupt code :

//------------------------------------------------------------------------------
//  SPI2 interrupt
//------------------------------------------------------------------------------
ISR(CPU12SPI2SR)
{
  UINT16 u16RxBuffer = 0;
 
  //DEBUG
  //PORTK |= 0x01;
 
  if (SPI2SR & SPI2SR_SPIF_MASK)
  //if (SPI2SR & SPI2SR_SPTEF_MASK)
  {
    //DEBUG
    //PORTK |= 0x02;
   
    // Read
    u16RxBuffer = SPI2DR;
    if ((u16RxBuffer) && (bSPI2_ACTT_Enable == TRUE))
    {
      TransmissionSCIPC_SPIR(1, u16RxBuffer);
    }
    // Transmit a word from the SPIT buffer
    if (u8SPIT_Counter_Buffer > 3)
    {
      u8SPIT_Counter_Buffer = 0;
    }
    SPI2DR = u16SPIT_Buffer[u8SPIT_Counter_Buffer++];
  }
  else if (SPI2SR & SPI2SR_SPTEF_MASK)
  {
   
   
    // Transmit a word from the SPIT buffer
    if (u8SPIT_Counter_Buffer > 3)
    {
      u8SPIT_Counter_Buffer = 0;
    }
    SPI2DR = u16SPIT_Buffer[u8SPIT_Counter_Buffer++];
  }
}

[bigmac]

Hello,

I am not familiar with the specific SPI module you are using, but I suspect that your "problem" may be, at least partly, fundamental to the general operation of a slave SPI.

Whenever the SPI master sends a word to the slave, it simultaneously receives a returned word from the slave.  The value returned will be that residing in the send buffer prior to the commencement of the transfer (/SS becoming active).

This would justify that there should be a one word lag, unless there is already a return word waiting in the buffer.  This lag could possibly extend to two words if the master should immediately commence the sending of the second word, on completion of the first.  After receiving the first word, there may be insufficient time for the slave to place its return word in the send buffer, prior to /SS again becoming active.  Placing a small delay between master transmissions should reduce the lag to one word.

Regards,

Mac

[GuillaumeDourne]

Hi,

Thanks for your attention.

I aggree with you about the one word lag. I don't know how to force the transmission buffer. I tried to set a value to the SPI2DR register in my initialization function, but there is no effect.

The Master transmission is trigged on an external signal. For my tests, a delay of severals seconds is used. So, there is no explication about the second lag. There is nothing in the freescale datasheet.

Guillaume.

[Pedro_]

Hi,

If you look at the block diagram of the SPI module, you'll notice the Data Register and the Shifter.

When the master clocks, the data in the Shifter is sent out.

Immediately after the Shifter becomes empty, data in the Data Register is moved into the Shifter.

The the Data Register is then filled with the frame received from the master.

By the time you write into the Data Register, the shifter was already loaded and this is why you see two frames 0x0000.

Remember that the Data Register Empty bit (SPTEF in the SPISR register) tells you when the SPI is ready to be loaded with data for tranmission.

If you poll or use an interrupt from this bit, you'll notice that it will allow you to write twice into the Data Register even before the master starts clocking. You would be, in esence, preparing the slave so the buffers are loaded with the data to transmit when the master starts clocking.

During normal operation, SPIF on SPISR (data available in Data Register) becomes asserted once the frame has been transmitted/received. After you read the register, then SPTEF becomes asserted, indicating that now you can load the data to transmit in the frame after the next.

If you use interrupts, remember that there is a single source for SPTEF and SPIF.

I hope this helps