Odd firmware or PIC issue

After a bunch of frustration troubleshooting and repairing bad solder joints on Lamarck's stepper controllers, I've now found a new issue: My Y-axis PIC has decided to stop talking correctly. When I use "echo 0 |./poke -d 3 -t /dev/ttyS0 -v" I get the following response:

<54><51><31><03><00><00><7b>[e3][54][51][00][00][02][81]CRC fail, got 129 expected 235
Read fail 1

Any ideas what might be causing this? I tried flashing a spare PIC with the same firmware and I get identical results. When I put the Z PIC on the Y board I get an ACK from the Z chip. With the Y PIC on the Z board, I get the same CRC error, so it appears to be an issue with the PIC itself, but that doesn't really explain the spare giving the same result (unless I somehow fried the spare in the same way as the original).

Any advice would be extremely appreciated.

You could load the Z code into the spare chip to rule out the chip being damaged. If it works in the Z position it looks like the Y firmware that is faulty.

Also might be worth removing the other nodes from the ring as the reply has to pass through them so could get corrupted on the way.

---

[www.hydraraptor.blogspot.com]

Could it be a noise issue on the Y-axis? Make sure you have bypass cap. Maybe try swapping cables?

OK, this makes no sense at all...

If I swap the Y and X PICs, the X PIC ACKs in the Y board, but the Y PIC gets a CRC error in the X board. IF I reflash the Y PIC as an X, it ACKs fine. IF I then reflash it back to Y, it gets a CRC error again - that suggest to me that it's a firmware issue, but I was able to get the Y firmware to talk fine earlier, so I don't know what is going on here.

Also, this is with only the power/comms board and one stepper controller connected. if I put a Y PIC in the socket I get a CRC error. If I put any other axis in there, I get ACKs.

That does sound odd.

Maybe try:

(a) diff the two .hex files you are using to program the X and Y PICs from, and make sure they only differ in the one address byte (02 for X, 03 for Y)?

(b) read the program out of the PIC when it is flashed as first X and then Y, saving the results into some new .hex files, and verify that these two read-out files also only differ in that one byte (one bit, really)?

Jonathan

I don't know what the heck happened, but it seems to be working now... I decided to run the stepper exerciser to see if it might give me different error messages that might be helpful. The stepper exerciser worked fine, and once I closed it, the Y axis board responded with an ACK every time I poked it. I'm very confused now, but at least it seems to be working now, so I'm happier

Perhaps the serial port was in the wrong mode, i.e not raw, and a character in the Y message had some special significance. Running the exerciser fixed it by putting the serial port in the right mode.

If you are interested in solving the mystery you could try rebooting the PC and then doing the poke test again.

As you might guess I don't like mysteries, in my experience if you ignore them and move on they always come back to bite you, or in this case probably somebody else.

---

[www.hydraraptor.blogspot.com]

it also could be something as benign as not having the chip fully inserted. i was having a hell of a time trying to drive my stepper motors, then when i got the stepper tester, i plugged it in and saw that only one set of coils was lighting up. i pushed the chip in while it was running on a hunch, and then both sets started lighting up and it worked great after that.

Can't discount bad or intermittent connections. This might include loose/broken/nearly-broken wires, contamination on sockets/pins etc. Glad you have it working. Sometimes just reseating components wear off a slight oxidation layer. I was in component testing for a while and saw that there were all kind of weird effects caused in trying to test circuits. At low voltage an oxide layer can form a resistive element, or a semiconductive element (like a diode). At higher currents the layer will be burned through and the expected results will now be correct. Just like to add a potential set of reasons that make it not worth pursuing You could however test/stress your wires into not working and then replace them. But I'm guessing you wouldn't want to go that far with the sockets.

I don't think bad connections are to blame because Eric reported no amount of swapping chips and boards changed the fact that Y was not working but simply running the stepper test fixed it. That points to s/w to me and unless the PICs store anything across power off it looks like a problem at the host end.

---

[www.hydraraptor.blogspot.com]

Maybe a pic lockup issue?

I don't think it was a bad connection - I replaced or resoldered basically everything between the PIC and the Power/comms, including the PIC itself and the MAX232. I even went so far as to solder wires directly from the header pins to the PIC socket so that I could eliminate a bad solder joint as the culprit. The explanation that makes the most sense to me is gremlin infestation, and that tells you how logical the problem has been.

I'm still getting intermittent packet loss while trying to run a build, so I picked up an oscilloscope and this week I'm gonna learn how to use it and hopefully be able to pinpoint exactly what the problem is.

Comms errors while the motors are running are likely to due to noise. You are using higher current motors than the standard RepRap so ground bounce may be an issue.

Make sure you have thick (pref 32/0.2) ground wires from the power board to the driver boards and keep them as short as possible. Although the comms is a ring, the power should be a wired as a star.

Whereas the steppers are lilely to create ground noise, the extruder motor will create RF due to the commutator sparks. Make sure it has a cap across the terminals as I suggested earlier and twist the wires together tightly.

---

[www.hydraraptor.blogspot.com]