cancel
Showing results for 
Search instead for 
Did you mean: 

SPI communication with 3 wire display

Danny0007
Senior

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: 

Danny0007_1-1708464524960.png

zoom in, single byte write:

Danny0007_2-1708464622941.png

what could be the reason? Thanks in advance.

 

 

32 REPLIES 32

"yeah", what I thought: very high speed as pin config is very sharp edges, creating a lot of EMI and cross-talks. Lower speed setting helps to get rid of cross talk.

Regarding your "E0 vs. C0":

I think, I see, your scope tries to decode SPI Mode 0: with the rising edge to sample the MOSI/MISO. But potentially you have configured SPI Mode 1 in the MCU:

https://www.analog.com/en/resources/analog-dialogue/articles/introduction-to-spi-interface.html

If you would sample with SPI Mode 1 - you should get a very clean C0 - at least on the second MOSI transaction.
Why the first one is longer as the second one - no idea. But on the second MOSI pulse, SPI Mode 1 (sampling with falling edge), would be the correct one.

Check your SPI Mode:

  • which SPI Mode do you need for your Slave device (often Mode 0 or Mode 3, Mode 1 and 2 are pretty uncommon)
  • check what is used by the scope as SPI Mode to decode (it looks like SPI Mode 0 to sample, but for sure "wrong" because it looks more like a SPI Mode 1 is generated)

It works actually this way (assuming SPI Mode 0):

When SPI Tx generates MOSI and the Slave (!) wants to receive as SPI Mode 0: it will sample MOSI with the rising edge.

Therefore, the data has to be changed on MOSI with the falling edge, so that it is stable long before the rising edge comes where MOSI will be sampled. One edge is to "setup" MOSI, the other edge is the "sampling" edge. Signal should be stable for a half clock period before the sampling edge and it changes again after a half clock period (again with the other edge).

But in your scope picture: MOSI changes with the same edge as SCLK would be used to sample. This cannot be right: you would not have any "setup time" for the MOSI signal. Very timing sensitive! Any offset in trace length between SCLK and MOSI line would change the timing relation for this "set and sampling" edge, depending on if MOSI or SCLK is delayed a tiny bit - you get wrong bits sampled.

At least your scope configuration is wrong, compared to what is configured for MCU to send SPI. Check also which SPI mode is needed by the Slave Device. Actually, your scope should use the same SPI Mode as your real slave device.

You are on the right track, just to check if the SPI Mode is the issue (and I think so).

Danny0007
Senior

Hi @tjaekel 

good news!!!

it works with this kind of CS signal:

Danny0007_0-1710455099874.png

the CS signal keeps always active until the last transfer session.

not works, when just set CS active for every transfer session like this:

Danny0007_1-1710455301709.png

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

Danny0007_0-1710455480916.png

I used Motorola mode(CPOL=0,CPHA=0) and keep the CS always active the whole transfer.

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

@tjaekel Thanks a lot again!!! I learned also a lot:)

 

 

Great, nice job.

The TI-mode I have never understood (why it is there, I have never used). The Motorola nCS behavior is the most common: nCS is active for the entire period of the SPI transaction. It toggles between SPI transactions (gets inactive). In your case: the nCS is a high active signal (not very common).

But good to know it works now for you. Well done.