CurtisHx
Posts: 3
Joined: Sun Sep 22, 2013 10:46 pm

SPI Chip Select line (CE0) goes low after transmittin

Fri Mar 28, 2014 7:43 pm

I have a raspberry pi v2 serving as the master, and a pic16f767 as a slave. I can transmit data from the pi to the pic just fine, but I cannot clock data out, and here's why:

The Pi is pulling the chip select lines (I tried both of them) low a few microseconds after transmission, and it's making my PIC think that it missed some data.

I'm using a simple Python program to transfer bytes to the PIC.

Code: Select all

import spidev

spi = spidev.SpiDev()
spi.open(0,0)
spi.max_speed_hz=500000

while 1:
   num = raw_input("Enter Hex: ")
   numHex = int(num, 16)
   ret = spi.xfer2([numHex])
   print ret[0]
I've attached a screen shot of the scope. #1 is the CS line for the PIC, 2 is the clock, 3 is SDO (of the pi), and 4 is SDI (into the pi). The yellow line is the write collision flag on my pic (PIC16F767). You can see on the left hand side, the chip select goes low for about 10uS after the chip select has been released. I tried connecting the SPI on the pi directly to the scope, and I get the same waveform. The pi is pulling the chip select line low after it's done transmitting.
Attachments
image.gif
image.gif (37.78 KiB) Viewed 6081 times

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: SPI Chip Select line (CE0) goes low after transmittin

Sun Mar 30, 2014 9:34 am

Mostly likely this is end of programme and the spidev closing the SPI port and reverting to some previous state. Also affects CLK as well with glitch

What happens on a trace if you put a time.sleep( 100 ) before the return? (need to import time as well)
Most likely this CS going low will move.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

blavery
Posts: 95
Joined: Sun Jul 01, 2012 2:57 am
Location: QLD. Australia

Re: SPI Chip Select line (CE0) goes low after transmittin

Mon Jul 14, 2014 8:51 am

I can confirm that there seems to be a spurious downwards glitch in the CE* line out of my Pi. The attached image is taken from the pigpio/PiScope. (The Pi is navel-gazing at its own GPIO pins, and the display screen is my laptop over network.)

The PiScope seems to have limited resolution, so my SPI speed is set quite low, but different speeds seem to show this glitch also.

The example shows a Pi talking (mosi) to an arduino in slave mode, with a return code (miso) being returned from the arduino. Traces (from bottom) are SCLK, MOSI, MISO, CE0. The glitch in CE0 is visible at right. Currently, I am not thinking that the glitch is stopping the correct transfers for me. I am detecting each character at the arduino by SPI interrupt after each character arrives. But I would not want to try an implementation that used SS* edges at the arduino, because there is an extra SS pulse that has no content.

For that image, the relevant Pi code (python using SpiDev) is a 2 character transfer:
spi.xfer([0x5a, 0x11])
There is no close() call, just repeated transfers (1/sec) of which this shows one sample.

Another interesting observation is that (to the best of my PiScope's resolution) both spi.xfer() and spi.xfer2() seem to operate under a single LOW of the CE* line. SPI (spidev) documentation suggests xfer() should assert CE* low separately for each character, and xfer2() should put all the package under one CE* assertion.

Maybe something not just quite 100.000% in the SPI implementation? (At least the SPI does seem to be talking with an arduino slave for me, better than the handicapped Pi I2C implementation to slave I2C arduino!)
Attachments
CE1.png
CE1.png (19.79 KiB) Viewed 5708 times
Last edited by blavery on Mon Jul 14, 2014 9:14 am, edited 1 time in total.

User avatar
joan
Posts: 14080
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: SPI Chip Select line (CE0) goes low after transmittin

Mon Jul 14, 2014 9:13 am

piscope gets its data from pigpio.

pigpio samples gpios at a rate set when it is initialised. The default rate is every 5us (200 thousand samples per second). The maximum rate is 1us.

I suppose usable results will be determined by http://en.wikipedia.org/wiki/Nyquist_frequency

If you use the pigpio daemon you can set the sample rate with the -s option.

e.g.

sudo pigpiod # default 5us
sudo pigpiod -s 1 # maximum sample rate

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: SPI Chip Select line (CE0) goes low after transmittin

Mon Jul 14, 2014 10:03 am

Other than the glitch the rest is as I would expect from almost any SPI master device, you tell it to transfer two bytes and it does. This allows for larger SPI formats having dealt with 8 to 32 bit formats (even 17bit amongst them), and other formats like EEPROM where you may want to read or write multiple bytes like EEPROM internal address and data byte(s).

Be thankful the SPI controller can deal with multiple bytes, I have seen controllers on other micros that if you want to send 16 bit format you have to software toggle pins for CE as the controller has habits of rasing CE between bytes.

If your Pi code only repeatedly sends bytes someone else could try it and replicate with an external scope

The glitch on most slaveices would perform a reset of SPI slave controller for transaction and then stop, may on some EEPROM type devices cause problems, in most cases no problem
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: SPI Chip Select line (CE0) goes low after transmittin

Mon Jul 14, 2014 6:59 pm

I can confirm that there seems to be a spurious downwards glitch in the CE* line out of my Pi.
Do you also get that glitch when you don't use python?

Code: Select all

echo -ne "\x01\x02\x03" > /dev/spidev0.0
Another python glitch report: http://www.raspberrypi.org/forums/viewt ... 55#p338055
Another interesting observation is that (to the best of my PiScope's resolution) both spi.xfer() and spi.xfer2() seem to operate under a single LOW of the CE* line. SPI (spidev) documentation suggests xfer() should assert CE* low separately for each character, and xfer2() should put all the package under one CE* assertion.
Assuming you use spidev from pypi, this is the source code: https://github.com/doceme/py-spidev/blo ... v_module.c
Looking at SpiDev_xfer(), it seems that SPIDEV_SINGLE is defined in your case, giving one SPI transfer.

kf5ibn
Posts: 1
Joined: Thu Jan 29, 2015 6:23 pm

Re: SPI Chip Select line (CE0) goes low after transmittin

Thu Jan 29, 2015 6:32 pm

Sorry for the necro, but I too am having the false CE0 pulse after transmission when using SPIDev.

It appears to happen regardless of whether I call writebytes or xfer/xfer2. It does not happen outside of SPIDev. If I use the echo command you mentioned:
notro wrote: Do you also get that glitch when you don't use python?

Code: Select all

echo -ne "\x01\x02\x03" > /dev/spidev0.0
I get a clean transmission with no spurious CE0 pulse. If I perform the same transmission with SPIDev I get the extra CE0 drop every time.

Pie314
Posts: 6
Joined: Sun May 29, 2016 5:28 pm

Re: SPI Chip Select line (CE0) goes low after transmittin

Mon Aug 29, 2016 11:01 pm

Sorry for reviving and old thread, but anyone find a fix for this? I'm seeing spurious CE as well, no clue why!??!?!

Have the pi hooked up to a xilinx, can see the CE line randomly deassert during a transmission using chipscope.

User avatar
joan
Posts: 14080
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: SPI Chip Select line (CE0) goes low after transmittin

Tue Aug 30, 2016 10:04 am

Pie314 wrote:Sorry for reviving and old thread, but anyone find a fix for this? I'm seeing spurious CE as well, no clue why!??!?!

Have the pi hooked up to a xilinx, can see the CE line randomly deassert during a transmission using chipscope.
I have a vague idea this was down to the old Linux driver. What does lsmod | grep spi report?

Return to “Interfacing (DSI, CSI, I2C, etc.)”