SPI Issues on Ubuntu Xenial image - dev release


#1

I am running the Ubuntu Xenial image - dev release on my Neutis.
I was having trouble talking to SPI devices, so I connected up the scope and I see that the CLK line is not stable “low” before CS goes low. This extra pulse, is causeing my device to think this is the first clock pulse. I have tried this in C and python both do the same thing.

Python Example from Scope


#2

Could you tell more detailed about your spi device? Please post the code that you run on Neutis.


#3

I have a custom board that I have used for years to test SPI communications with new platforms.
I have used the same C source code on many different platforms and it has always worked just fine.
I have tried it on RPI, BeagleBoneBlack, NanoPi Duo, NanoPi NEO Air, NanoPi NEO Core 2, NanoPi K2, NanoPi NEO2, Banana Pi Zero, Samsung Artik 520, 530 & 710, TechNexion, Variscite, Odroid-C0 & RoadRunner by acmesystems.it.

Let me just say, even though I have allot of kits, none of them are more exciting to me than the Neutis!

There are 2 mcp23s17’s on the board used in SPI mode. All of the outputs are connected to led’s. So there are 32 leds on this board.

I can’t include the C code here are its in multiple files. But it does and looks the same on the scope as the python does. With the exception of a bit faster timing from CS going low to when the first clock starts, but it too has that blip on the clock like when CS goes low.
Here is the python code

import time
import spidev

MCP23S17_MANUF_CHIP_ADDRESS= 0x40
MCP23S17_CHIP_1=	0x40
MCP23S17_CHIP_2=	0x42

# Used For 16 bit mode ONLY
IODIR=           0x00
IPOL=            0x02
GPINTEN=         0x04
DEFVAL=          0x06
INTCON=          0x08
IOCON=           0x0A
GPPU=            0x0C
INTF=            0x0E
INTCAP=          0x10
GPIO=            0x12
OLAT=            0x14


spi = spidev.SpiDev()           # create spi object
spi.open(0, 0)                  # open spi port 0, device (CS) 0
# Set SPI speed and mode
spi.max_speed_hz = 200000
spi.mode = 0
#spi.cshigh = True
#spi.lsbfirst= True
#spi.bits_per_word= 8



print("Hello Jimbo")

spi.xfer2([MCP23S17_CHIP_1, IOCON, 0x0c, 0x0c])
spi.xfer2([MCP23S17_CHIP_1, IODIR, 0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_1, GPPU,  0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_1, IPOL, 0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_1, GPINTEN, 0x00, 0x00])

spi.xfer2([MCP23S17_CHIP_2, IOCON, 0x0c, 0x0c])
spi.xfer2([MCP23S17_CHIP_2, IODIR, 0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_2, GPPU,  0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_2, IPOL, 0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_2, GPINTEN, 0x00, 0x00])




spi.xfer2([MCP23S17_CHIP_1, OLAT, 0x00, 0x00])
spi.xfer2([MCP23S17_CHIP_2, OLAT, 0x00, 0x00])



try:
    while True:
        spi.xfer2([MCP23S17_CHIP_1, OLAT, 0xff, 0xff])
        spi.xfer2([MCP23S17_CHIP_2, OLAT, 0xff, 0xff])

        time.sleep(0.3)         # sleep for 0.1 seconds


        spi.xfer2([MCP23S17_CHIP_1, OLAT, 0x00, 0x00])
        spi.xfer2([MCP23S17_CHIP_2, OLAT, 0x00, 0x00])

        time.sleep(0.3)         # sleep for 0.1 seconds
except KeyboardInterrupt:       # If Ctrl+C is pressed,
    spi.close() 


#4

Any ideas what is going on ? Really need SPI to work properly to move on with project.


#5

Please share your setup, take a photo of Neutis with your spi device, how it is connected. Also could you please post the following oscillograms? Like you have posted:

  1. Neutis spi lines
  2. Other board that you have spi lines

Please do not change oscilloscope settings during measuring data.

CLK line is pulled up by SPI device before transaction I guess.


#6

In the OP, the scope channels are:
Green: PC3/CS0
Blue: PC2/CLK0
RED: PC0/MOSI0

The only 2 pullups I have on my board are ~RESET & ~CS.


#7

Everything looks okay!

Could you please tell more detailed what exactly doesn’t work? Your device misses some transactions or spi totally doesn’t work.


#8

Do you see how the clk line goes low after CS has fallen? The SPI slave IC thinks this is the first clk signal. Because CS has already fallen. The strange part is that clk was already low just before CS went low, so what is this pulse all about.

3ba4baf6fe13423e9fadd29a089180124352e3a7_1_690x388


#9

Yes, I see. This is normal behaviour, SPI is not initialized before CS goes low, this line can be low or high.
If you want to have the stable high CLK, you need to add pull-ups to device tree. But I think it is not relevant.

You said that your SPI device is not working, could you please tell more detailed what exactly doesn’t work?
I have tested SPI today with some devices and I have the same oscillogram, it works okay.


#10

I have made a video showing the issue more clearly I hope. It can be seen here.

Pullups or pulldowns should not matter because its a clock line which is a output. It’s up to the master to drive it.


#11

Thank you fot the video.

Please try other SPI modes, there are four modes. Let me know what the result will be.

  • spi.mode = 1
  • spi.mode = 2
  • spi.mode = 3

#12

mode 3 will make it work. But the device is a mode 0 peripheral. I also noticed that even when doing this in C mode 0 does the same thing. My micocontrollers ESP32, Atmel. Motorola, all use mode 0 for this device and work fine and verified on the scope.
This is what a proper timing for MODE 0 should look like. Take note of the clock line state when CS first goes low.


#13

If I understand you right, mode 3 works. Good!

I looked through the mcp23s17 datasheet, this chip supports mode0 and mode3.
Your device shouldn’t detect a first falling edge according to the mode 0 specification.
You said mcp23s17 doesn’t work, it is strange and not correct behaviour. So I think mode 3 is a solution for you.

Also I agree that it is strange that Neutis has a CLK pulse at the beginning of transaction, but it works correctly according to the mode 0 specification as I mentioned before.

Please let me know what you think.


#14

The reason it work in mode 3 is because of the issue with the CLK line being in the wrong state.

It does not work correctly for mode 0. Mode 0 speck is what I have shown in the table diagram. CLK should be already low when CS transitions from high to low, and this is not the case.


#15

In your case I suggest using mode 3 if it is acceptable for you.

We will research an issue with mode 0. Thank you very much for the catch!
By the way, if someone wants to use mode 0, it works, but apparently not with all devices.