Using hardware SPI on Feather M4 doesn't appear to work

[makermelissa]

When trying to run this using Hardware SPI (SCK and MOSI), it doesn't appear to be working at all as in none of the lights do anything. I was able to run just fine on the Raspberry Pi using Hardware SPI.

[ladyada]

what happens if you slow it down to 1mhz
does software SPI work
did you try powering the LEDs from 3.3V

[makermelissa]

It’s at 1MHz. I tried 1KHz too. Software SPI works fine.

[makermelissa]

I didn’t try powering at 3.3v.

[ladyada]

did you verify signal comes out on the hardware SPI pins with an oscilloscope?

[makermelissa]

No, I haven’t done that yet. I was stopping for the night and was just putting the issue here. Thanks for the suggestions on some things to try.

[ladyada]

oki!

[makermelissa]

Here's with Hardware SPI:

Here's with Software:

One thing I noticed right away between the two is that between sets of pulses the line is high with hardware and low with software.

[ladyada]

try different hardware MODEs

[makermelissa]

Yeah, that's what I was thinking.

[makermelissa]

Just to be complete, here's the output on the Hardware SPI on Raspberry Pi (which is working). This matches the working CP Software SPI output with MOSI being low between pulses.

Playing with Phase and Polarity only seemed to affect the clock and not MOSI. I'll keep digging.

[makermelissa]

Ok, I can't seem to find a way to make MOSI go low when idle and it seems to be losing bytes here and there. Changing Phase to 1 has limited success in flashing the first light, but the colors is wrong. So I'm just going to finish up the guide and note this.

[dhalbert]

The resting level of SERCOM MOSI in SPI mode on AVR, SAMD21 and SAMD51 is high. I see this both in CircuitPython (I tried the latest version (ASF4) and also 2.3.1 (ASF3). I also tried the simple program below in Arduino on a Feather M0 and also on an ItsyBitsy 32u4, and MOSI also remains high when quiescent.

So my guess is that this code never worked with hardware SPI on any typical microcontroller platform.

#include <SPI.h>

void setup() {#include <SPI.h>

void setup() {
  SPI.begin();
}

void loop() {
  SPI.transfer(0xff);
  delay(100);
  SPI.transfer(0x00);
  delay(100);
}
  SPI.begin();
}

void loop() {
  SPI.transfer(0xff);
  delay(100);
  SPI.transfer(0x00);
  delay(100);
}

[makermelissa]

That's pretty much the conclusion I was coming to. Thanks for chiming in.

[ladyada]

ok lets leave this here for now as a warnin'

[dhalbert]

If you look at the Arduino library, it has this line after doing either hardware or bitbang SPI:
https://github.com/adafruit/Adafruit-WS2801-Library/blob/master/Adafruit_WS2801.cpp#L212

  delay(1); // Data is latched by holding clock pin low for 1 millisecond

I don't see any explicit delay like that in this library. It just does an SPI write. Maybe just add time.sleep(0.001) (or 0.002 if that doesn't work) after the write.

[makermelissa]

Ok yeah, that's something to try that might just work.

[makermelissa]

Hey, adding a delay did fix it!

[makermelissa]

I should say it almost fixes it. The first LED seems to want to be a different color, but we're on the right track.

[dhalbert]

I guess I'd take a look at the Saleae output from https://github.com/adafruit/Adafruit-WS2801-Library, but you're probably already doing that.

[makermelissa]

Looks like it was a premature celebration. I had phase = 1, but I'm having trouble getting consistent results. I'm gonna put this on hold and we can circle back later, but playing with delays looks like it might have promise. Like you said, another thing to try when we get back to it is to see what the output of the arduino library looks like.

[makermelissa]

Since I'm working on the Arduino pages, I thought I would hook up the Saleae to it. Looks like MOSI alternately starts high then low, then repeats, but the important thing is it sets the MOSI bit between clock pulses. I think the CP driver is doing it mid-pulse and that's a problem.

[kevinjwalters]

@dhalbert I had this running on a Gemma M0 with some LEDs found on Amazon UK. The code was per example in https://github.com/adafruit/Adafruit_CircuitPython_WS2801#usage-example - is that hardware or software?

[dhalbert]

@kevinjwalters The sample code using D2 for SCK and D0 for MOSI. The library attempts to use hardware SPI and falls back to bitbang. On a Gemma M0 I was able to create a busio.SPI(board.D2, board.D0), so it would appear to be hardware SPI.

[kevinjwalters]

I forgot that I also tested both hardware and s/w with and without the bitbang fix on a CPX (M0-based) board, details shown in #4 (comment)

[makermelissa]

Yeah, I just mentioned in the guide that timing on hardware isn't consistent from board to board.

[kattni]

@makermelissa Has this been resolved?

[makermelissa]

@kattni, I didn't see a notification for your question. No it hasn't.

[IoaSman1]

Did anyone solve this problem? I have the same Issue using an Adafruit Central M4 or an Adafruits Itsy Bisty M4 connected with Hardware SPI to an TI ADS1299 ADC. When I configure the ADS1299 registers over SPI, there is a non-reliable data transfer (for example I send "0xCE" value to configure a register and the ADC reads "0x60" value. I tried a Hardware SPI with SAMD21 based board and there is no issue the values are sent correctly. Anyone has any idea what's the deal with SAMD51 boards and Hardware SPI , or how I could fixed ? (Not to mention that I tried different speeds 1MHz, 4MHz, 8 MHz, all the available SPI modes and Bit orders without any lack) Thanks

[tannewt]

@IoaSman1 If you are trying to write to a device that is not a WS2801 please file a separate issue on CircuitPython here: https://github.com/adafruit/circuitpython/issues

[FoamyGuy]

I tested this on a Feather M4 9.2.1 and confirm it still does not work with SCK and MOSI pins. I also tried on Feather ESP32 S3 and found that it does work successfully on SPI pins on that device.

I am not sure that I have the ability to troubleshoot it much further, but wanted to at least test it and report the current situation on latest circuitpython version.