Skip to main content
Visitor II
January 3, 2025
Question

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

  • January 3, 2025
  • 3 replies
  • 1489 views

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?

    This topic has been closed for replies.

    3 replies

    Super User
    January 3, 2025

    > 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.

    Visitor II
    January 4, 2025

    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, .....).

    SoCalJimAuthor
    Visitor II
    January 4, 2025

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

    SoCalJimAuthor
    Visitor II
    January 4, 2025

    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);

    Super User
    January 4, 2025

    > 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.

    SoCalJimAuthor
    Visitor II
    January 16, 2025

    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.

    Visitor II
    January 17, 2025

    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...)