Errors while Communicating with SPI Daisy Chain Devices

Mr_John_Smith 2017-01-27 12:37:54 UTC #1

(This is more of an electronics question)

I have 7 SPI devices connected along a 20 pin ribbon cable. The cable is between 7 to 8 feet, long. The distance between the µC and the last device is the full length (approx 8 feet away). When I send zeros (0x0), I am able to get the data back correctly. However, when I try to send any commands (e.g. 0x36), which is supposed to have a response (0x2E88) I am getting wild, unpredictable values instead. I need some idea as to what could be wrong. I know this description is far to vague to properly diagnose the problem, but I've got to try something; can't just stay stuck for another month.

General Facts about the system:

PHITEK 2017-01-27 13:11:39 UTC #2

@ Mr. John Smith - Glad to see some of your progress with these stepper motor controllers.

Just a few quick questions:
1. What .NETMF processor board are you using?
2. What clock frequency are you using on the SPI.Configuration command?
3. Do you have pull-up resistors on the stepper motor controller chip select signals?

Phil

Mr_John_Smith 2017-01-27 14:04:33 UTC #3

@ PHITEK - µC is Fez Cobra 3; G120. Frequency is 1Khz. There is no pull up resistor. The driver is now designed for a variable number of daisy chained devices. It auto detects the number and sets up accordingly. It also now has an Execute method so you can "cache" multiple commands before sending them, so you don't waste cycles sending NOPs.

PHITEK 2017-01-27 14:22:21 UTC #4

@ Mr. John Smith - Well from my testing and previous posts to this forum the G120 was the only processor that attained the desired SPI frequency of 1 KHz, so that should work in your favor.

I would still try a pull-up resistor on your chip select signal, maybe something like a 4.7 K ohm to your 3.3 volt rail.

My experience is with dedicated chip selects to the L6470, where one stepper motor controller worked fine, but as soon as I added a second L6470 the stress testing program would fail.

Another question, not sure how all 20 conductors in your 20 pin ribbon cable are allocated but if possible, you could try to put extra ground connections between the SPI MISO, MOSI, and Clock signals?

Phil

Brett 2017-01-27 16:17:58 UTC #5

8 feet of antenna. Yep, I'd seriously worry about that. GND shielding around signal pins is a good idea within your ribbon cable would be a step in the right direction

Dave_McLaughlin 2017-01-27 22:15:24 UTC #6

Agree on the grounding idea although at 1Khz it should work well enough but the reflections on the cable will still most likely still be present. Put the pull up on the end device at the far end of the cable.

Mr_John_Smith 2017-01-28 01:38:16 UTC #7

If I need pull ups on the CS, then will I need that on the Data lines also?

Mr_John_Smith 2017-01-28 12:16:55 UTC #8

I applied a variable resistor (10K) to the CS line. I think there's been an improvement, but I can't say for sure. Would increasing the resistance help?

PHITEK 2017-01-28 16:42:18 UTC #9

@ Mr. John Smith - You need to decrease the resistance typically, to improve the condition I think you are experiencing. Hence I recommended a 4.7 K ohm pull-up.

The LPC178x datasheet page 72 states that LOW level output current is min. of 4 mA @ 0.4 volts. So this should be a very safe value to try next.

I would still try isolated in SPI signal with a ground wire in the ribbon cable. Is this possible in your project?
Then try some pull-ups on the SPI signal lines would be my next option.

Phil
P.S. The issue I am thinking of with the chip select signal is this signal is typically used internally to mark the end of a SPI bus transaction and cause the chip to begin some internal operations with the received data in the case of the trailing edge.

Frogmore 2017-01-28 21:05:15 UTC #10

You are really asking for trouble with 7-8 feet of wire on SPI. That is a lot of propagation delay and capacitance that the far end needs to overcome to get to the near end. Here is an app note from TI that has some good information on what you can do to increase the reliability of the system.
http://www.ti.com/lit/an/slyt441/slyt441.pdf

The good news is that you are lowering the clock rate which makes it more likely things will stay synchronized. SPI is actually pretty tolerant of that, since it expects slaves to change on one edge, but doesn't read till the next one. But, the far end still has to charge up the capacitance of the line to raise the signal level at the near end (that takes time and power, which some devices don't provide).

If you have access to an oscilloscope, you could look at the signals at each end and see what they look like to see what might be causing the real problem.

Frogmore 2017-01-28 21:16:45 UTC #11

Looking at the datasheet for L6470 it lists the maximum rise time for the clock as 25ns. I am guessing, but with that much cable it would be really hard to meet that rise time requirement. While you can probably make it work at that distance, I expect that it will not be reliable unless you put a lot of effort into it and use extra parts.

Mr_John_Smith 2017-01-28 23:17:01 UTC #12

@ Frogmore - I'm aware of the propagation delay, hence the low speed. The previous version of this solution had 10 feet of wire and managed to operate at 5Khz, for extended periods of time.

I was re reading the datasheet and saw that the CS line already has internal pull up resistors. This must be something else then.

PHITEK 2017-01-29 14:32:41 UTC #13

@ Mr. John Smith - Your previous solution was wire and not a ribbon cable is that correct? Where there any other significant changes done between the two projects?

The resistance value of the pull-up resistor on the chip select signal is important, since it will change the RC time constant all else been equal. The internal pull-up resistance is between 335K and 565K, so at best with 9 L6470 connected in parallel, the pull-up resistance would only be about 37.5K at best and likely larger value. This is no were near what a 4.7 K ohm resistor even at 5% tolerance is going to do to change the effects of the signal on your ribbon cable.

As @ Frogmore suggested some test equipment and a more formal treatment of the SPI bus signals as a transmission line will yield a solution.

Phil

Mr_John_Smith 2017-01-31 14:08:22 UTC #14

Ok, Update. I found and fixed loose wire problems and code problems. So far I have gotten the drivers to start talking sense, at the low speed of 1khz. Sadly one of the motors is dead, and just humms in place.

I took the resistor of the CS line, but I don't think the drivers are receiving the message to run correctly. More testing and playing with the CS resistor values will be needed. Really wish I had a BSc in Electronics at this point but hey, I have you guys

Mr_John_Smith 2017-02-04 13:08:06 UTC #15

Motor replaced, variable resistor on the CS line at the far end of the cable (That's the end furthest from the µC right @ Dave?) and the system is working. Motors are turning 100% of the time (as opposed to intermittently without the CS resistor).

Next Challenge, speeding it up. Let's see if I can get 1Mhz on the bus.

Mr_John_Smith 2017-02-10 08:35:39 UTC #16

Well the bus did not achieve 1Mhz. Also, it's not working again at all. Funny thing is, When I used to run the old machine at 5V I never had these intermittent problems. So question, when a system is running at 5V as opposed to 3v3 volts what is the crossover voltage point from low to high? Is it still 1.5V or is it 2.5V? (i.e. one half VCC).

PHITEK 2017-02-10 10:03:47 UTC #17

@ Mr. John Smith - In the case of the L6470 at 3.3V or 5V supply voltage, the high logic level is a minimum of 2 volts.

Without more details of the term "not working" is too vague. A bad motor control parameter will cause that condition.

Good luck
Phil

Frogmore 2017-02-10 10:42:16 UTC #18

Some links to help explain why what you are doing is fraught with problems. (But always remember that some aeronautical engineer said bumblebees shouldn't be able to fly)

You really need a scope that will allow you to see what the signals look like at the various points. With a cable that long, you will have reflections and slow rise times that will cause the signals to look bad. They might work, but they will not be reliable (but your definition of reliable might be different than mine).

Mr_John_Smith 2017-02-12 19:41:06 UTC #19

Right so it turns out it was really working in the first place; there are a lot of errors communicating with the drivers.

Having read the documents and links, frogmore, I understand the concept of propagation delay and treating the system as distributed therefore requiring transmissions lines. What perplexes me now is how do I get the G120 to hold off sampling MISO for a specified amount of milliseconds?

Mr_John_Smith 2017-02-17 11:22:03 UTC #20

I've fixed a few bugs with the driver and test code. This resolved some of my problems. I had to remove the CS pull up for testing. Now I am noticing new phenomenon. It seems that at startup the drivers don't respond properly, however after about 30 seconds it seems that the communication start working properly. The L6470 is known to emit jibberish when it's not powered properly. Could it be that the inital communication problems could be associated with the initial charging rate of the decoupling caps on each board?

Do systems have a settling time at initial power on? Is it normally measured in nano seconds or seconds?