SPI doesn't work on Rpi Zero W, Stretch

[CaptainBisquick]

I've verified the pin is correct and I can light an LED by setting it high. This is true for both SCLK (pin 23, GPIO11) and MOSI (pin 19, GPIO10). I'm trying to drive some Adafruit DotStar LED's. If I don't set the pins high or low, SCLK stays low, and MOSI stays high. SCLK should be emitting a stream of 1's and 0's so it should cause and LED to flicker, but it doesn't. I've been able to make everything work with an Adafruit Feather M0, and these tests worked with that device, so it should be the same with the pi.

I don't have a logic analyzer or oscilloscope.

lsmod

Code: Select all

Module                  Size  Used by
cmac                    3134  1
bnep                   11949  2
hci_uart               21222  1
btbcm                   7917  1 hci_uart
bluetooth             376017  24 hci_uart,bnep,btbcm
spidev                  7034  2
brcmfmac              269955  0
brcmutil                9911  1 brcmfmac
cfg80211              527260  1 brcmfmac
rfkill                 21373  6 bluetooth,cfg80211
snd_bcm2835            23131  0
snd_pcm                97889  1 snd_bcm2835
snd_timer              22706  1 snd_pcm
snd                    68784  3 snd_timer,snd_bcm2835,snd_pcm
i2c_bcm2835             6433  0
spi_bcm2835             7424  0
bcm2835_gpiomem         3791  0
uio_pdrv_genirq         3718  0
uio                    10166  1 uio_pdrv_genirq
fixed                   3029  0
i2c_dev                 6642  0
i2c_bcm2708             5740  0
ip_tables              12512  0
x_tables               20921  1 ip_tables
ipv6                  384901  20

cat /boot/config.txt

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
dtoverlay=spi0-hw-cs

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Enable UART
enable_uart=1


dtparam=i2c_arm=on
dtparam=i2c=on
dtparam=i2c_arm_baudrate=100000

ls /dev/spi*

Code: Select all

/dev/spidev0.0  /dev/spidev0.1

cat /etc/os-release

Code: Select all

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Please help. I need to get this working ASAP.

[CaptainBisquick]

I see that wiringPi is deprecated, but I had installed it before I learned this. These are the commands I used to verify the pins and that they work (no solder joint issues)

MOSI

Code: Select all

[email protected]:~ $ gpio -g mode 10 output
[email protected]:~ $ gpio -g write 10 1

SCLK

Code: Select all

[email protected]:~ $ gpio -g mode 11 output
[email protected]:~ $ gpio -g write 11 1

[joan]

wiringPi is not deprecated. Using the gpio utility function to load the SPI and I2C drivers is not needed if device tree is being used.

[CaptainBisquick]

wiringPi is not deprecated. Using the gpio utility function to load the SPI and I2C drivers is not needed if device tree is being used.

I read somewhere that it’s deprecated now and also that device tree can’t be disabled anymore.

[joan]

I reckon you might have misunderstood my answer at https://raspberrypi.stackexchange.com/q ... 0786#70786

[CaptainBisquick]

I reckon you might have misunderstood my answer at https://raspberrypi.stackexchange.com/q ... 0786#70786

Yup, that’s the one I saw. As you can see, I’m still stuck, even though everything looks correct.

[ericcooper]

I thought that when the spidev module is loaded, the kernel handles driving the SPI clock and chip-select lines during transfer system calls. So unless one of those operations is ongoing, you might not see any activity on the clock line. I could be totally wrong, but SPI transfers work fine on the Pi Zero W when using those operations (read, write, ioctl via spidev).

[CaptainBisquick]

I thought that when the spidev module is loaded, the kernel handles driving the SPI clock and chip-select lines during transfer system calls. So unless one of those operations is ongoing, you might not see any activity on the clock line. I could be totally wrong, but SPI transfers work fine on the Pi Zero W when using those operations (read, write, ioctl via spidev).

When I run my Javascript code nothing happens. Here's a sample run in the REPL:

Code: Select all

$ node
> const SPI = require('pi-spi'); const spi = SPI.initialize('/dev/spidev0.0');
undefined
> const dotstar = require('dotstar');
undefined
> const ledStrip = new dotstar.Dotstar(spi, { length: 32 })
undefined
> ledStrip
Dotstar {
  length: 32,
  ledBuffer: <Buffer 00 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 ... >,
  colorBuffer: <Buffer e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 ... >,
  offBuffer: <Buffer 00 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 ... >,
  device: 
   { clockSpeed: [Function],
     dataMode: [Function],
     bitOrder: [Function],
     write: [Function],
     read: [Function],
     transfer: [Function],
     close: [Function] } }
> ledStrip.set(25, 50, 50, 50, 0.5)
undefined
> ledStrip.set(24, 50, 50, 50, 0.5)
undefined

[FTrevorGowen]

...
When I run my Javascript code nothing happens. Here's a sample run in the REPL:

Code: Select all

$ node
> const SPI = require('pi-spi'); const spi = SPI.initialize('/dev/spidev0.0');
undefined
> const dotstar = require('dotstar');
undefined
> const ledStrip = new dotstar.Dotstar(spi, { length: 32 })
undefined
> ledStrip
Dotstar {
  length: 32,
  ledBuffer: <Buffer 00 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 ... >,
  colorBuffer: <Buffer e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 ... >,
  offBuffer: <Buffer 00 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 00 00 e0 00 ... >,
  device: 
   { clockSpeed: [Function],
     dataMode: [Function],
     bitOrder: [Function],
     write: [Function],
     read: [Function],
     transfer: [Function],
     close: [Function] } }
> ledStrip.set(25, 50, 50, 50, 0.5)
undefined
> ledStrip.set(24, 50, 50, 50, 0.5)
undefined

Pity you didn't mention you're using Javascript before now. SPI definitely works for me using 'C' code both via 'C' system calls, and 'C' based wiringPi methods. However it's also possible to write simple sets of (test) data from the command line eg.:

Code: Select all

printf "\017\001" > /dev/spidev0.1
printf "\017\000" > /dev/spidev0.1
printf "\014\000" > /dev/spidev0.1

NB: Octal strings with printf are more robust/portable than, say, using echo and hex strings**
Trev.
** for more info. see this thread:
viewtopic.php?f=44&t=190475&hilit=echo#p1196540

[CaptainBisquick]

Pity you didn't mention you're using Javascript before now. SPI definitely works for me using 'C' code both via 'C' system calls, and 'C' based wiringPi methods. However it's also possible to write simple sets of (test) data from the command line eg.:

Code: Select all

printf "\017\001" > /dev/spidev0.1
printf "\017\000" > /dev/spidev0.1
printf "\014\000" > /dev/spidev0.1

NB: Octal strings with printf are more robust/portable than, say, using echo and hex strings**
Trev.
** for more info. see this thread:
viewtopic.php?f=44&t=190475&hilit=echo#p1196540

I don't see any change when running these. I tried them with both /dev/spidev0.0 and /dev/spidev0.1. Perhaps using wiringPi I can send PWM on SCLK just to verify that the LED will flicker (as it does with the Adafruit Feather).

[EDIT]

When I run gpio -g blink 11, SCLK blinks.

[FTrevorGowen]

What SPI clock speed have you setup? You could also try using @joan's piscope to monitor the GPIO's:
http://abyz.me.uk/rpi/pigpio/piscope.html
OOC, what does gpio readall report? (post in code tags please)
Trev.

[CaptainBisquick]

The pwm and clock commands both don't work (no activity from the LED). SCLK is wired to a 100ohm resistor in series with the LED, going to ground.

Let me back up to the beginning. I had originally referenced this issue: https://raspberrypi.stackexchange.com/q ... 7729476c66

Like this person, I also get this:
$ gpio load spi

Code: Select all

gpio: Unable to load/unload modules as this Pi has the device tree enabled.
  You need to run the raspi-config program (as root) and select the
  modules (SPI or I2C) that you wish to load/unload there and reboot.
  There is more information here:
      https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=97314

As mentioned earlier, we're not supposed to use this with device tree. I run sudo raspi-config and enable SPI under "5 Interfacing Options", and restart. Still, no change.

What SPI clock speed have you setup? You could also try using @joan's piscope to monitor the GPIO's:
http://abyz.me.uk/rpi/pigpio/piscope.html
OOC, what does gpio readall report? (post in code tags please)
Trev.

I don't know what clock speed is set, I haven't seen mention of it and haven't attempted to set a clock speed. I will look into piscope now, thanks for the link.

$ gpio readall

Code: Select all

 +-----+-----+---------+------+---+-Pi ZeroW-+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5v      |     |     |
 |   3 |   9 |   SCL.1 |   IN | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 1 | ALT5 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT5 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI | ALT0 | 1 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO | ALT0 | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |  OUT | 0 | 23 || 24 | 1 | ALT0 | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | ALT0 | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+-Pi ZeroW-+---+------+---------+-----+-----+

[CaptainBisquick]

I'm not able to get piscope working. My machine is a Mac and there's no instructions provided for MacOS. I have XQuartz so I tried using the `ssh -X` approach but this is what I get when I run piscope.

Code: Select all

[email protected]:~ $ piscope &
[1] 8905
[email protected]:~ $ piscope: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

[CaptainBisquick]

I downloaded Jessie from 2017-07-05. Now the LED on SCLK lights up briefly when I run any of the following commands:

Code: Select all

printf "\017\001" > /dev/spidev0.0
printf "\017\011" > /dev/spidev0.0
printf "\014\111" > /dev/spidev0.0

When I run the following JS code, I get another flash of light, only on the last line of this snippet:

Code: Select all

const SPI = require('pi-spi')
const spi = SPI.initialize('/dev/spidev0.0')
const dotstar = require('dotstar')
const ledStrip = new dotstar.Dotstar(spi, { length: 32 })

When I use a command like ledStrip.set(25,50,50,50,0.5), I don't get any activity.

I'm only able to see this if I run SCLK directly to the LED, circumventing the level shifter circuit. It seems the voltage isn't high enough to operate the level shifter. Meanwhile, the voltage from MOSI is high enough as this LED is staying on, and this pin is routed thru the level shifter before the LED.

[rpdom]

I notice your "gpio readall" output looks a little different to mine with SPI enabled. You have:

Code: Select all

|  11 |  14 |    SCLK |  OUT | 0 | 23 || 24 | 1 | ALT0 | CE0     | 10  | 8   |
|     |     |      0v |      |   | 25 || 26 | 1 | ALT0 | CE1     | 11  | 7   |

and I have

Code: Select all

|  11 |  14 |    SCLK | ALT0 | 0 | 23 || 24 | 1 | OUT  | CE0     | 10  | 8   |
|     |     |      0v |      |   | 25 || 26 | 1 | OUT  | CE1     | 11  | 7   |

I don't use SPI for dotstar LEDs on that Pi, I use it for an RFID reader, but the differences may be significant.

[joan]

Setting the GPIO high or low will set it to be in OUTPUT mode. The driver will not know and the SPI circuitry will no longer be connected to that GPIO (i.e. the SPI hardware is busy toggling the clock line but the clock line is no longer routed to the GPIO). The GPIO needs to be put back into ALT0 mode for SCLK to work (or the Pi needs to be rebooted).

[CaptainBisquick]

I have it working now. The reason the LED wouldn't light for certain lines of code is because the set() method doesn't update the LED's, sync() has to be called to push the update.

I haven't gone back to Stretch, now that things are working, I'm going to focus on the next task.

The lights occasionally freak out, changing to all random colors. This will happen while the processor is obviously busy with other tasks. It would be nice to know what exactly the cause of this is. The issue that the clock line doesn't run continuously like it does on any regular microcontroller, concerns me. To resolve this issue, it seems my options are:
1) port my JS code to a systems language like C or rust, and add JS bindings so I can use JS for network communications
2) port my JS code to C for Arduino and attach a small Arduino as a slave device, responsible for driving my DotStar LED's
3) upgrade to a board with a faster CPU (probably a beaglebone since they're better engineered anyway, they boot faster, headless support included out-of-the-box, their I2C support is better, etc)