Can a STM32L496RG read a 20-bit SSI signal with a SPI interface?

[SoCalJim]

I have to read a 20-bit SSI signal. I connected it to a SPI interface as a “Receive Only Slave”.

It appears that the SPI interface is limited to 16-bits.

We could live with the first 16-bits of a 20-bit word. Can the SPI receiver do that?

[TDK]

> We could live with the first 16-bits of a 20-bit word. Can the SPI receiver do that?

Yes, it could.

A better solution would be to use a 10-bit word size and read two of them. That gets you all 20 bits.

[tjaekel]

Yes, the SPI config should be able to set 4bit... 32bit word size: for instance: set 4bit and wait for 4 words (or as TDK has mentioned (2x10bit, I am not sure if 10bits is possible or just 4,8,12,16,...?).

You might be able to configure also 16bit as word size and receive one "complete" word. The problem is just: you will get 4 additional bits afterwards (nSS is still active, the SPI Slave still receiving). Even you could check that one word (16bits) was received - the next cycle is not really completed. And no idea what what happens if the SPI Receiver remains in an incomplete state: it will potentially not start again to receive a new word (unless you reset it and start it again.

Best is really to check if you can figure as "N times Xbits_as_word" (to make sure the entire transaction would be complete as 2x10 or 5x4, .....).

[SoCalJim]

I am trying to capture this waveform. Note that it only has CLK and DATA.

[SoCalJim]

It looks like the STM32L496’s SPI RX FIFO is either 8-bit or 16-bit.

Would you expect this to capture the above waveform: 

hspi3.Init.DataSize = SPI_DATASIZE_10BIT;

...

uint16_t buf[2];

HAL_SPI_Receive(&hspi3, (uint8_t*)buf, 2, 1000);

[TDK]

> Would you expect this to capture the above waveform: 

Yes. Note that the call needs to happen before data is sent. And it will time out after 1 second.

You will have to reconstruct the 20-bit word from two 10-bit words each stored as a uint16_t. Lower 10 bits of each uint16_t will have half of the data.

[SoCalJim]

So I just realized that the clock I'm trying to read is 2 MHz and the update rate is 20 KHz. Is that too fast?

[SoCalJim]

Here are the 20-bit signals I’m trying to read.

If I attempt to read two 10-bit words (or two 16-bit words), does the SPI receiver need a Tp microsecond separation between words?

   

[SoCalJim]

I’ve tried reading a pair of 16-bit words and a pair of 10-bit words and the data never lines up with what I’m seeing on the scope.

What if I tried to read that signal with GPIOs? I would interrupt on the rising edge of the CLK and read the state of the DATA pin. Would that work with the 2 MHz clock rate? The system clock is 8 MHz.

[tjaekel]

Your scope screenshot looks OK to me (where it does "never lines up"? SPI mode 0 and it looks OK to me).

No idea what you want to connect (as external slave). But based on the waveform you have provided:
- your external chip wans to see a Tp (a "pause" on the clock), in order to realize a "new transaction" (CMD).
  sure, if you do not pause, your external chip might be confused. So, make sure after 10bits sent you provide Tp.

Other then this - I do not see any issue.

For testing it:

- configure the MCU master as bi-directional (full-duplex)
- connect MSIO with MOSI (no external chip)
- and see that you get back what you have sent (check via "loopback" that you get what you send)

2 MHz with "system clock 8 MHz":

No idea what you mean (SPI SYS clock as 8 MHz or entire MCU as 8 MHz? Such a slow MCU?).
If MCU runs core with 8 MHz but you want to handle 2 MHz - and now you think to use GPIO bit-banging for SPI...
How can it work?:

- running MCU with 8 MHz and handling a 2 MHz clock, with GPIO (and INTs) - NO WAY!
  --> you need more time for all the instructions (you are just 4x faster on instructions, and you might need
       N instructions (assume at least 10), to realize a GPIO signal change

Handling signals as GPIOs and running MCU instructions... your MCU should run at least 100 times faster as the clock you want to process... I do not see any benefit trying to use GPIOs in bit-banging mode to emulate SPI
(esp. when it looks to me you can generate already the 10bit transactions...)