SPI loading issue?

[Hawaslsh]

Hello all,

I have a system that requires I program 8 different SPI devices within a single chassis. Originally I had two raspberry Pis in the system, one programming 4 of the devices and another programming the other 4. I used 2 separate Pis because there were a host of other GPIOs i needed to control other devices. That solution worked great, apart from needing two Pis and needing 2 ethernet cables to run the system.

However, I wanted to compress the design down to 1 raspberry pi with an added GPIO expander, MCP23017, to cover what the second raspberry pi was intended for. The figure above shows what I tried. There was a PCB over the Pi attached to the 40 pin connector on the PI with 4 devices sharing the SPI lines (SCK, MOSI, MISO). Each device had its own dedicated GPIO for their listen enable. A second PCB housed the MCP23017 and daisy chained the same SPI lines from the Pi to the other 4 devices. I run into an issue trying to program the all the SPI devices at once. I can successfully program some of the devices when only a number/combination of devices are hooked up to the circuit. For example, If I disconnect the MCP23017 board from the PCB over the Pi, i can successfully program all the devices connected to the PCB over the Pi. However, if I simply add the SPI connection to the MCP23017 board, with no devices actually connected the MCP23017 board, all the SPI devices are left in an unknown state and do not operate correctly. Another example, I can have 1 device connected to the PCB over the PI and 2 connected to the MCP23017 board and program them successfully.

All this leads me to think there is a loading issue? Is there a common solution to this problem? I know its not common, but can pull up resistors be used to help SPI? Also, all the SPI devices have 33 Ohm resistors in series with their SPI lines, all the devices are the eval boards of the chips.

Fun testing quirk, when i tried to probe the data and clock lines with an oscilloscope, i was never able to program any chips successfully. I was using a common oscilloscope probe and set the tool to high impedance, but the loading affect of the probe itself caused the same issue.

Happy to provide more context, thanks in advance,
Sami

 

[KlausST]

Hi,

For my designs it's rather common to have more than 4 slaves on one SPI.

Daisy chaining SPI is not recommended.
Programming / accessing more than 1 slave at the same time is not recommended, too.

So access one after the other should work.

Klaus

 

[Hawaslsh]

Hi,

For my designs it's rather common to have more than 4 slaves on one SPI.

Daisy chaining SPI is not recommended.
Programming / accessing more than 1 slave at the same time is not recommended, too.

So access one after the other should work.

Klaus

Perhaps daisy chaining wasn't the best wording. Each SPI device has their SCK, MOSI, MISO lines in parallel with the Pi. Each device has their own GPIO to toggle their Listen enable lines. The programming sequence programs one at a time.

 

[KlausST]

Hi,

Then I see no problem.
Maybe lenghty wiring, maybe unsuitable cables,
Maybe accidentally multiple devices selected at once..

Usually I use a 74HC138 decoder to select the devices.
* Binary input (low line count),
* one common SS line (easy for software)
* prevents from selecting multiple devices at the same time.

Klaus

 

[Aussie Susan]

You could also put a buffer (or 2, or 3...) on the MOSI line so that the RPi is not trying to drive all slave devices at once. (In the old days at least we used to call this 'fan-out').
The MISO lines could probably be alright as they should be tri-stated when not selected so the only issue you may have is the length of the lines (as mentioned above). Even so buffers may help there as well as long as you tri-state them appropriately as well.
Susan

 

[Hawaslsh]

Maybe lenghty wiring, maybe unsuitable cables,

Thanks for the quick replies!
One more clue i just discovered while testing. One of the chips has no problem being programmed no matter how many devices were hooked in parallel, the LMX2595. I didn't mention this in the original post, but we are using all evaluation boards. The eval board for the LMX2959 has 12K resistors in series with all the SPI lines. Where as the other chips have 33 Ohm (LMX2820, ADMV8818) and 330 Ohm (ADMV8913) in series with the SPI lines. Think that could be causing some issue?

In Regards to table length, some of the cables are quite long. Some are on the order of 12-15 cm. The cables are twisted wires ending in standard 0.1mm spaced housings for PCB headers to mate with the evaluation boards.

You could also put a buffer

I thought about that, but when i probed the signals using an oscilloscope the voltage levels were correct ~3.3V. However, using the oscilloscope did exacerbate the problem leaving all chips in an undefined state. All the datasheets for the devices in question had logic highs listed as >1.4V. I realize the voltage doesn't say much about the current, but i assumed SPI inputs didn't draw much current?

 

[KlausST]

Hi

The MISO lines could probably be alright as they should be tri-stated when not selected

I don't know how to understand this, since I expect MOSI and SCK to be tristated anyways.

Usually I don't use series resistors, only on sensitive devices like high res ADCs.
Everything above 1k is too high. 33R and 330R are O.K. .. I doubt they are much of use.

A single evaluation board makes sense, but many evaluationboards does not. (My opinion), because they cause additional signal capacitance and GND bounce. I don't like the wires at all, because - especially the GND impedance - makes signal worse. I rather rely on a GND plane.

Klaus