BBGW SPI0 data corrupt

Hey, cross posting from seeed studio forums.

tldr: clocking in data on spi0 looks cattywompus, spi1 ok

Was noticing an issue with some custom hardware/software that utilizes both spi channels, was working on beaglebone black prior. Wanted to make it easily reproducible so flashed a bbgw and used adafruit bbio library as an example.

steps:

1.) flash BBGW with latest production image 4.4.15-ti-r37 (other kernel versions and imaged used as well)

2.) prevent sound drivers from loading, as they conflict with spi1:

cd /lib/modules/4.4.15-ti-r37/kernel/sound/core

mv snd.ko snd.ko.bkp

3.) install adafruit library from source (need latest greatest, pip upgrade didn’t work)

cd ~
git clone GitHub - adafruit/adafruit-beaglebone-io-python: Adafruit's BeagleBone IO Python Library
cd adafruit-beaglebone-io-python
python setup.py install
cd …

4.) reboot

5.) use wires to loopback MOSI to MISO, both channels

short P9.18 and P9.21 with a piece of wire (SPI0)

short P9.29 and P9.30 with a piece of wire (SPI1)

6.) put the following into a file and run it

from Adafruit_BBIO.SPI import SPI
def run(x,y):

print ‘running spi {} {}’.format(x,y)
spi = SPI(x,y)
spi.mode=2
spi.msh=4000000
bytes2send = range(20)
print ‘sending {}’.format(bytes2send)
print spi.xfer2(bytes2send)
spi.close()

run(0,0)
run(1,0)

result:

sending [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
[128, 7, 28, 31, 112, 231, 124, 127, 192, 135, 156, 159, 240, 231, 252, 255, 0, 7, 28, 31]
running spi 1 0
sending [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]

so, spi1 works in loopback. spi0…wtf? there are places where it looks like it’s double clocking MISO (like a 0x00000001 becomes a 0x00000011), some of it just looks random. Works fine on beaglebone black.

Thoughts?
If anyone has spi0 working on a bbgw would love to hear about the setup.
Thanks!

resolved, 100pF cap on SPI0 clock near the grove connector causing reflections, resulting in double-clocking data. sigh.

Hey Joe,

spi0 on my BBGW also gave me the wrong result when I ran the spi test code by shorting p18 and p21. How did you solve your problem? Replace the cap???

Howdy, correct, had to completely remove the cap on the spi0 clock. Hope that helps!

Thanks! Could you tell me where is the cap on the board? Already read the BBGW’s SCH, but still couldn’t figure it out…
And do you think this is the problem caused by specific kernel versions (I’m using ubuntu 16.04, 4.4.12-ti-r30)? I assume using SPI0 for communication is really common among BBGW users, but after I searched the whole forum, just you and me encountered this CLK hardware design issue??

Pretty confident it’s not kernel version. Actually explored that line of thinking a little, but there’s a u-boot spi tool you can use to test before the kernel even loads, and you can replicate this issue with that.

FYI response from Seeed regarding the existence of the caps is that they’re for EMC related to the UART on the Grove connector.

This is the location of the spi0 capacitors (Should only need to remove the one on clock, but I removed both, forget which one is which). Near the sd card slot, underneath the grove connectors:

Thank you very much! I will try to remove it and see if any luck with the spi0…

The 100pF cap, C204, seems to me to be almost useless without a series bead (or resistor) to divide down the EMI signal (2.4GHz).

That said, if UART2 pin is re-purposed as SPI_CLK, then I agree that C204 could be problematic.

Board layout issue, crosstalk most likely…

It’s not crosstalk, 2 capacitors are the answer - one on CLK line and one on D0 (MISO) line, used also as RX/TX of UART2 on Grove connector.

Here are some more details and a picture with said capacitors marked, as the one posted by Joe Phaneuf is no longer available: https://stackoverflow.com/a/46351310/3217805

Just in case I’m also attaching the picture here.

W dniu środa, 1 marca 2017 18:05:44 UTC+1 użytkownik James Pereira napisał: