I'm a complete beginner at this so please don't overlook any silly mistakes that a complete beginner may have made.
I have a home-brewing project, where I am attempting to hook up multiple MAX31865 thermometer sensors, connected by SPI, to a Raspberry Pi. The MAX31865 boards are pre-made (Playing with Fusion) and have a pair of chips each. There are also a couple of DACs hanging off the same SPI bus. I used a multiplexer to set the CS line to each part individually.
Everything was looking fine – I get temperatures back from the chips, and the DACs can control the boilers through burst-fire-controllers. But, in some temperature ranges, the thermometers gave back odd readings. Looking with a logic analyser, it seemed that sometimes the first bit of one of the bytes was getting mangled. Unplugging any two of the dual-MAX31865 boards makes the anomalies go away. At this point I figured/googled that it was likely due to an SPI fan-out problem.
I built a board with a pair of SN74AHC244s buffers (16 inputs/outputs total). I tied all output-enables to ground so they're always enabled. My idea was that the Pi's SCLK & MOSI link to 6 inputs each, then I go point-to-point from the outputs to the boards (2 x DAC, 4 x dual MAX31865). The other 4 inputs take the 4 MISO lines from the boards to the Pi (DACs have no output, so 1 for each of the 4 thermometer boards). Power is being supplied from the Pi's 3.3v pins.
I have connected it all up to a single dual MAX31865 board and early indications with the logic analyser were good: I can see data going into the board and back through the other side. There's the MOSI request to the chip, then the MISO reply.
But the Pi doesn't like it at all. I seem to get mostly 0s back across the board even though I can see correct data in the logic analyser.
So I dropped back to a simple wire loopback test – MOSI attached to MISO on the "far side" of the SN74AHC244s. The logic analyser decodes the bytes back to exactly what was sent. But the Pi returns 0s. If I wire MOSI to MISO directly then a loopback test is fine and I get back exactly what was sent, so I think the Pi's pins are fine.
Directly connecting the thermometer to the Pi also works correctly.
Software wise I have tried using the bcm2835 library directly, and the loopback test is the one mentioned here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md#troubleshooting
I'm fairly convinced this is not a software issue, which leaves me thinking that there's a hardware issue I am missing.
I have tried the following:
-
voltages in and out of the SN74AHC244s: 3.3v.
-
SCLK/MOSI/MISO through the SN74AHC244s: fail.
-
Only MISO through the SN74AHC244: fail.
-
Change SPI speeds. Through the SN74AHC244s it's "better" but still drops loads of bits. Direct wired loopback it's fine up faster than I need for the thermometers.
-
Logic analyser on the loopback on the far side and the MISO input on the Pi: both signals are identical and correct according to the analyser. The Pi still returns 0s.
-
Tested all input/output pairs on the buffers with a 3.3v source (just voltage, not signal). Looks fine.
Can anybody see anything that I am missing here? Could the latency of the SN74AHC244s be causing issues? My sample-rate on the logic analyser is 20MHz – perhaps the Pi cannot read the SPI fast enough?
I can post the logic analyser trace if it helps.
Thanks for reading.
Update:
I have been looking at the latency/propagation delay angle:
http://electronicdesign.com/microcontrollers/isolate-your-high-speed-spi-bus-despite-long-propagation-delays
That article says: "One way to maintain synchronicity is the drastic reduction in clock rate until the clock pulse width is extended to approximately twice the propagation delay."
For the SN74AHC244: "tpd @ Nom Voltage (Max) (ns)" = 11.
From the SPI library: BCM2835_SPI_CLOCK_DIVIDER_128 = 128, /*!< 128 = 512ns = = 1.953125MHz */
Based on that I don't think that propagation delay is the problem after all (also explains why slowing down the SPI clock way below that still doesn't work).
Unfortunately I now have no idea where to look next (other than to try returning a slave clock into the Pi on a 2nd "fake" SPI… but that's going in a direction I want to avoid). Ideas very much appreciated.
Update 2:
Please excuse MSPaint diagrams, I tried Eagle and Visio but didn't get far with either before the swear box was getting full; that's a fight for another day!
This simple loopback doesn't work (where I put "test" is where I put logic analyser probes):
This also doesn't work:
Update 3:
I have come up with a theory on what I did wrong, and I'm feeling pretty silly. It's also something which I didn't put explicitly on the diagram, so many apologies to the kind people who have commented (you both have made me take a better look at things, I have learnt more, and that's much appreciated).
I think the issue is with "the other 4 inputs take the 4 MISO lines from the boards to the Pi". What I did was tie the outputs from the 1Yn x 4 together and tied their single output-enable to ground. While tieing them together works from the thermometer boards straight to the Pi as at any one time three float… because I put them all together on the 74AHC244, I presume that's thus removing the "floaty" tri-state aspect and giving me:
(one solid 3.3V signal line + (3 x floaty mostly 0V))/4
as a signal voltage. My guess is that the signal's still enough to be a 1 for the logic analyser, but the Pi actually expects a "proper" 1.
I think I was testing certain things on the Pi-out lines while considering that it was the same as MISO coming back through; of course it's not. On one side I have, say the clock, going to all inputs at once, and independent outputs, and on the other side the MISO has 4 independent feed lines that then join on the output side.
So, to fix it, for the MISO set, I intend to swap out the 74AHC244s for something with an output-enable per output, then link each output-enable to the DRDY lines on the dual MAX31865 boards.
Bruce: I'll answer your questions in case I'm missing anything else, and because I appreciated the question (your comment about my text not matching and the "high MISO" is what triggered me to think "oh wait, it does matter doesn't it?").
"What are your CKPOL and CKPHA settings?"
I'm using Mode 3 SPI: POL and PHA are both 1.
"How long is the cable between the Pi and 74AHC24?"
10cms (4 inches).
"Do you have a bypass capacitor between Vcc and GND?"
No. I was assuming the feed from the Raspberry Pi was already "clean" (as that's got a 5v source itself). If I should still add a bypass then please let me know.
"What does the Pi return if you hold MISO high?"
As you probaby guessed from above – mostly 0s… but then high isn't high because of my mistake.
"does not match your diagram. Do you mean 1A2 and 1Y2?"
I didn't think it mattered… now I still think it doesn't matter for that example, but my omission of the joining wires definitely mattered.
Best Answer
Buffering may not necessarily be the issue. I would double check that the chip selects aren't being asserted for multiple sensors at the same time. If more than one is asserted, this would describe the exact problem you are having where the data coming back is bad, and removing one device fixes it. This is due to bus contention (each sensor is trying to drive MISO, whereas only one should).
You mentioned using a multiplexer to select the chip selects, I think you meant to say decoder? (like a 74HC138 3 to 8 decoder). That's what you need for a circuit like this.
If you are sure you need to buffer the MISO outputs, then you can use a multiple-buffer part like the 74HC125 and have each sensor's MISO output run to an independent buffer on the '125. The decoder producing the chip selects would enable the buffer output such that only one device has an enabled buffer at any time.
Also try running things at a low speed first. You can always crank up the SPI clock rate after you've verified operation in the KHz range.