long SPI frames not possible, KEA?

[dsula]

Hi,

After much time spent debugging SPI slave functionality I came to the conclusion that it is not possible to communicate frames longer than single bytes with the KEA8. What I mean is, the PCS (slave select line) can be low only during one byte and must be de-asserted to high to transmit multiple bytes.

Is that correct? I'm asking because I cannot find any documentation regarding this limitation in the user manual, so I'm keeping my hopes up that I made a mistake somewhere.

Thanks, Daniel

[sajchaulagain]

I know this is a late reply. But, in case, if anyone is having the same problem with slave, then change the CPHA bit to 1. The slave can only send one byte during 1 cycle when CPHA bit is 0, but can send multiple bytes when CPHA bit is 1.

[dsula]

It is one of those things that will probably make me go mad.

Is it possible that they got a bug in the chip?

Receiving multiple bytes while PCS (slave select) is low, works without a problem. I follow the datasheet and do this:

   s = SPI0_S;

   d = SPI0_D;

However TRANSMITTING back from the slave to the master does not work, because SPTEF only gets set when PCS (slave select) goes high. I again follow the data sheet and read back S first, before writing D.

   s = SPI0_S;

   SPI0_D = d;

As described in the datasheet SPTEF goes to 0 after writing 2 bytes (1st goes directly into the SPI shift register, 2nd byte goes into the TX buffer). However even after receiving several bytes from the master, the SPTEF never goes high again, thus the TX won't ever allow new data again. Only after PCS (slave select) goes high is the SPI shift register actually loaded with the next TX byte and SPTEF goes high.

I would now argue that they have either a bug in the chip or a bug in their documentation. I whittled all these down to bare metal, removing all IRQ functionality, yet it still doesn't work as advertised.

[adriancano]

Hi,

The SS output is available only in master mode during normal SPI operation, this means that only the master can control the Chip Select signal, therefore the Slave behavior will depend on the master behavior. You need to check how the master device is handling the Chip Select line.

In this case the Chip Select by the master is recommended to be driven with a GPIO pin to control the state of this pin during transmissions. With this we can ensure the CS line low during transmissions of more than 1 byte.

Hope this information can help you

Best Regards,
Adrian Sanchez Cano
Technical Support Engineer
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dsula]

Adrian,

You did not understand the problem. Let me explain again step-by-step.

I'm using the KEA8 as an SPI slave, driven by an external master. Obviously the slave select (pin called PCS on the KEA8, but I call it SS here)  is an input to the KEA8.

I reduced the problem to a few lines of code. This is the SLAVE code running on the KEA8.

n = 0;

while(1) {

// wait till the transmit buffer is empty
     while (!(SPI0_S & SPI_S_SPTEF_MASK));

// load transmit buffer with new value to be transmitted to master
     SPI0_D = n++; 

}

This only works, if the frame length of the master is 1 byte. Or in other words. The master sets SS low, transmits one byte, sets SS high. Rinse and repeat.

This does not work if the master transmits more than 1 byte per frame. If the master sets SS low, transmits one byte, then transmits another byte and then sets SS high, the KEA8 does NOT send the expected data to the master. In fact only the first byte sent after the SS goes low is as expected.

I found the problem to be that the KEA8 does only load a new value into its shift register and only sets bit SPTEF=1 when SS goes high, not when a complete byte was shifted out. Obviously this problem also results in the SPI slave not working in cases where no SS pin at all is desired, but SS is permanently tied low.

I cannot believe that this was a conscious design decision of the chip designer, but have to assume that this is a bug, especially also because the RX side works as expected (meaning the KEA8 is capable of receiving multi bytes frames, it's just not capable of transmitting them).

I still hope I made a stupid mistake somewhere. Having to switch to a different MCU to solve this problem will be a lot less pleasant.

[davidsherman]

Ah, my mistake, I missed that you were using it as a slave.  Only things that come to mind are the note that the S register must be read with SPTEF set to transmit another byte.  I'm assuming the master is still transmitting multiple bytes and you're just not seeing anything sent back from the slave after the first byte.  Maybe the receiver has to be cleared as well before transmitting more bytes?  I'm familiar with using it as a master (the KE06 module appears identical), but it seems strange it would have such a limitation as a slave.

[davidsherman]

If you're using the slave select line automatically, then yes, having used the SPI in the KE06 it doesn't stay low after sending one byte.  Better to use the slave select manually to send multiple bytes, and I have not had any problems using it that way.

[dsula]

There's no manual slave select operation in the KEA, as far as I can tell. There's only automatic/manual slave select for master operation, but not slave. Unless again, I'm missing something so obvious....