SPI communication with 3 wire display

[Danny0007]

Hi community,

I have a display, which has only CLK, DI and CS pin for SPI communication. It uses TI protocol.

The original driver is only working with raspberry pi, I try to import it into my custom STM32 MCU board, the CLK and CS signals seem okay,  Only the MOSI signal is always low. it seems no data is really sent to the display. 

here is the signal capture from logic analyzer. 

The whole write sequence: 

zoom in, single byte write:

what could be the reason? Thanks in advance.

[Tesla DeLorean]

Bit pointless to guess why.

Diagram all the connections, and provide a data sheet to the module or controller you're attaching too.

Either it isn't strapped in SPI mode, or expects CS to be low going.

[tjaekel]

Are you sure your SPI Enable (NCS) is high active?
I see, your SPI enable is high when SPIC SCLK is sent.

OK, not related to "why MOSI" is not there:

• have you configured and connected the MOSI signal properly?
• if you ALT config for MOSI is wrong or you grab the signal on a wrong pin...

Your waveform should be correct, even nothing is connected: check the config for the MOSI signal (pin and ALT).
And check if NCS should be high.

Hint: configure MOSI pin as GPIO and see, when you toggle GPIO, if it comes out on the correct header pin. If not: you are on the wrong pin. If it works, but not with SPI: you have not configured the right pin as MOSI.

[Danny0007]

Hi @Tesla DeLorean @tjaekel 

thanks for reply!

this is signal capture from raspiberry pi, you can see the CS pin is also high during write-operation.

there are only 3 pins(clock, MOSI, CS), I thought the data are transformed only in this direction: uC----> display. how to explain the read-operation in the sequence?

*********************************************************

Here is my hardware connection to display:

datasheet

here is SPI2 init function:

here is pin definition:

[Tesla DeLorean]

Show the code sending the data

[Danny0007]

[Andrew Neil]

Please use this button to properly post source code - not as images:

[Tesla DeLorean]

Ok, this is getting really laboured.

You keep showing very narrow context.

And how are you calling this? Show the code and the data array that it's moving. Perhaps print out the values from the array as you're sending it? An array of zeros will transmit as shown in the logic analyzer traces.

You're using an BlueNRG-LP part? 

https://www.st.com/en/wireless-connectivity/bluenrg-lp.html

You're connecting to WHAT display part? Provide link to manual for display, and provide a diagram of exactly how it's wired.

Could anything be shorting the MOSI pin?

Can you drive it up/down as a GPIO?

[tjaekel]

1. configure MOSI as GPIO pin and toggle it:
   verify that you do not have a short on board
2. Why do you drive NSS signal high - still not clear for me:
   - I have never seen a SPI slave chip which uses NSS signal as "high active"
   - actually, the name SPI2_NSS says: "Negative/Negated Slave Select" - a clear indication that NSS must be
     low in order to select a slave (I see it also in BlueRNG-LP datasheet: it is low active)
3. OK, you use just 3-wires, but you still configure a full-duplex (4-wire) SPI (LL_LPI_SPI_FULL_DUPLEX).
   It should not matter really so much.
4. BUT:
   You configure to use "SW_NSS Mode": LL_SPI_NSS_SOFT
   But I think here you might have an issue:

OK, you want to use SW_NSS: you drive the NSS signal yourself (as GPIO pin). Fine, works (if low active).
But you have to drive low for enable and high for disable. You do it in the reverse order (your NSS signal is "high-active", even I can see on your scope picture). I am pretty sure, this cannot be right (but it does not answer yet why you do not see MOSI toggling. BTW: on your RPi scope picture - even there I do not see MOSI toggling).

Maybe, you think: when you drive NSS high - it enabled the SPI2 as master, to start sending. NO, there is not any correlation!.

I think: you have to enable still the Master, even in SW_NSS mode: it is not enough just to do LL_SPI_Enable(BSP_SPI2);
There is a bit inside the Master, called SSI bit (SSM = 1 enables "SW_NSS" mode, but you have to "toggle" still this SSI bit: this enables the SPI Master so that it can start to send!

Maybe you mixed it up: this SSI bit is "high active", you have to set it to 1. It acts like a NSS signal. The Master is listening on the NSS input: if "bus is occupied, NSS is low - the Master will not start to send". Even you do not drive neither use the NSS in HW mode - you have to "enable still NSS via this SSI bit" (I think).

So, this bit should be set to 1, but the GPIO for NSS signal is set to low.

Strange is just that you see a SCLK signal. But I saw in BlueRNG-LP datasheet: the SPI on this side can be a Master as well. Are you sure you are talking from MCU as SPI Master to a SPI Slave?
If the module is also acting as SPI Master - it would generate the clock (and you, as MCU, have to act as a SPI Slave). Maybe the SCLK comes from the SPI Master on the other end (it is not your signal). Actually not, because your SCLK signal is aligned with the NSS you generate.

So, check:

1. Is there really a SPI Slave at the other end?
2. Is NSS not really "low active"?
3. Have you forgotten to set (toggle) also the SSI bit (in SPI2 Master)?
4. Does MOSI toggle in GPIO mode?
   (or is a SPI Master maybe driving against it, somebody ties the MOSI signal down?)

a SPI Master still needs the SSI bit (in order to start a transfer)? I think.

A SPI_NSS signal is "low active" (as NSS stands for)

[tjaekel]

Oh, BTW: how do you connect Master and Slave? Which MCU do you use?

On my STM32U5A5 MCU PA6 is SPI1_MISO.

Is PA6 really MOSI? If it is MISO - it would explain why you do not see anything (an input on MCU, but with NSS high the slave would not send anything). Is PA6 floating? (you can check with scope, if you touch the probe with fingers, to see 60Hz noise).

• check if PA6 is really MOSI (and not MISO)
• if a mistake on schematics: the STM32 MCUs have a feature to SWAP MISO and MOSI 

BTW: if your device on other end is not a Slave, a Master instead: it could explain why do you see SCLK: if it has the similar feature to "check NSS even as an input on master" (if "SPI bus is busy" before starting as Master Tx) - your high active NSS lets the other Master assume, the bus is free (and now the other master generates SCLK, talking to you as a slave).