1
\$\begingroup\$

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:

  1. voltages in and out of the SN74AHC244s: 3.3v.

  2. SCLK/MOSI/MISO through the SN74AHC244s: fail.

  3. Only MISO through the SN74AHC244: fail.

  4. 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.

  5. 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.

  6. 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): simple loopback

This also doesn't work: MAX31865 link

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.

\$\endgroup\$
  • \$\begingroup\$ At what speed are you running your SPI clock? \$\endgroup\$ – brhans Jul 22 '15 at 20:54
  • \$\begingroup\$ I have set the divider to 128, which equates to 1.953125MHz. \$\endgroup\$ – TimLux Jul 23 '15 at 4:45
  • \$\begingroup\$ Are you sure you've got your MOSI & MISO the right way around? In your point 5 above you refer to "MOSI input on the Pi", which is wrong. Can you draw a circuit diagram of how you've got everything connected up? \$\endgroup\$ – brhans Jul 23 '15 at 11:35
  • \$\begingroup\$ Sorry, yes, MISO on point 5! I'll change it in the question, and try and do a diagram later. Essentially though, I have MOSI on the Pi going to 1A1 on the buffer, 1Y1 going to the MOSI on the thermometer. Same for SCLK (Pi's CLK->1A2->1Y2->device). MISO on the thermometer going to 1A3 on the buffer. 1Y3 then going to MISO on the Pi. Removing the device and connecting 1Y2 to 1A3 doesn't work (but again, looks perfect on the logic analyser). \$\endgroup\$ – TimLux Jul 23 '15 at 11:47
  • \$\begingroup\$ What are your CKPOL and CKPHA settings? How long is the cable between the Pi and 74AHC24? Do you have a bypass capacitor between Vcc and GND? "5... both signals are identical and correct according to the analyser. The Pi still returns 0s." - what does the Pi return if you hold MISO high? "I have MOSI on the Pi going to 1A1 on the buffer, 1Y1 going to the MOSI on the thermometer." - does not match your diagram. Do you mean 1A2 and 1Y2? \$\endgroup\$ – Bruce Abbott Jul 23 '15 at 22:02
0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

I understand, that it has been over 3 years now, but maybe somebody finds this useful. Also, would be nice if OP could explain what happened there and how it was resolved.

Without going too much in details, general SPI debugging info:

  1. MISO/MOSI/SCK pins should fan out directly from Pi to devices, multiplex only CS pins. Buffering might be necessary only if you have level differences (e.g. 3V3 MCU and 5V device)
  2. Due to high number of devices, there might be an issue with Pi being unable to ensure correct signal levels (basically, sum of the leakage currents is a bit too large to handle by Pi I/Os). Just to be sure, add pull-ups, say, 10k to VDD
  3. Logic analyzer might decode just fine those signals that are in the gray area (between stated V_low and V_high), ICs are more picky about it. Hence the point 2. Better use oscilloscope to verify the signal levels and shapes
  4. Reduce the frequency to the bare minimum for testing, 100khz, 1MHz. Once you have stable communications, you can try to increase it gradually. I doubt that the amount of data warrants such speeds.
\$\endgroup\$
  • \$\begingroup\$ OP here. I had to abandon this particular project due to multiple other life happenings, and it went in a box I cannot currently locate. From what I remember, I did solve this particular problem. IIRC it was because the voltage was being split somewhere and was enough for a 1 on my logic analyser but not on the PI. I think it was because of me enabling all of the outputs all of the time on the buffer, rather than just the output that was required, and I fixed it by ensuring that only the output required was on (by adding another octal buffer in front). \$\endgroup\$ – TimLux Apr 12 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.