Universial controller board testing problems

I've run into a problem going through the first serial test of my
universal controller board. I was first running into:

> ./reprap-host.sh
Opening port /dev/ttyS0
Experimental: JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyS0
Device at address 8 not present
sendMessage error - retrying
sendMessage error - retrying
sendMessage error - retrying
sendMessage error - retrying


Doing some reading on the forums, I tried the poke program,
and the first packet seems to work:

> echo 0 | ./poke -d 2 -t /dev/ttyS0 -v
<54><51><31><02><00><00>[54][52][30][00][02][bd][ACK Received]

but sending a second packet fails:

> echo 0 | ./poke -d 2 -t /dev/ttyS0 -v
<54><51><31><02><00><00>[54][53][30][00][02][32]Got NAK
<54><51><31><02><00><00>[54][53][30][00][02][32]Got NAK
<54><51><31><02><00><00>[54][53][30][00][02][32]Got NAK
<54><51><31><02><00><00>[54][53][30][00][02][32]Got NAK
<54><51><31><02><00><00>[54][53][30][00][02][32]Got NAK
>

powering down and powering up I can always seem to get one packet
successfully sent (trying 'echo 1 2' causes the led to blink), but any
subsequent packet gets NAKed.

Is this a problem with my build or a firmware issue? I'm using the
hex file from the tarball on sourceforge.

thanks
-nick

Nick,

I'm not sure, but this sounds more like an issue with your construction (or even with your PIC??). You might try flashing a second PIC with the Y-axis code, and poke-ing address 3 rather than 2 and see whether the results are the same? If they are, and assuming your PIC programmer verifies the PIC flash as being successful, that would suggest to me you're looking at some sort of electronics construction, serial port setup, or wiring oddity, rather than a firmware bug.

The firmware on SF is known to work for several people, so it is unlikely to be the source of this kind of issue, IMO.

Just to check: You seem to be running under Linux, and to be using a normal hardware ( non-USB ) serial port -- right? And your PowerComms card tested out fine when used solo, shorting the T and R lines and testing with minicom?

A careful reading of the output from

$ stty -a -F /dev/ttyS0

might reveal some strange serial port setting that is causing this, though I can't think of what specific setting would cause these symptoms??

Jonathan

After building a second board with a new pic and running
into the same issue, I went through and rechecked everything
and it turned out that one of the jumpers I had on the left
opto endstop header wasn't actually shorting the pins.

Everything's working now. Thanks for the help.

-nick

Nick did you recently get these boards and is the big capacitor pushed far back from the power connector? I have 5 boards, 4 of the old design with the Large Cap close to the power connector(12 VDC) and one with the Cap pushed back that I got recently. Guess which one gives me timeout resend errors? The new board with the cap pushed back also moved the bypass cap for the pic a little bit further from the pic.Bypass caps should be as close to the 5VDC and gnd of the pic as possible. I can communicate with all the old boards, (One with the large cap close to the power connector). I have reflowed the solder connections and checked continiuty, I think the pic is acting up. I need to see a schematic to be sure.