Sun has found a rather significant bug in the command buffer of the
eDemo board. Apparently it uses a ring buffer with no protection in
case the head pointer catches up to the tail and overwrites it. The
command buffer is pretty small so it only takes a few commands close
enough together to trigger this problem.

The effect of this is to corrupt commands sent to the eDemo board, if
there is also serial I/O going on, and commands are sent to eDemo
faster than they can be processed.

We see this as corrupted LED color commands, and lost serial messages
between SPOT and TrackBot.

We originally reported symptoms to Sun over a year ago but without
some hard evidence (which is hard to get), they didn't believe us.
Now someone else at Sun Labs has come up with a specific test case
and also dug into the source code to see the likely explanation.

Sun is reportedly working on a fix which we will test as soon as it's
available. They also may add a true blocking read to the UART, which
would be a huge improvement, and eliminate the need to poll the UART
to see if data is available.

In the meantime, be aware of this and don't send commands to eDemo
(including UART access) "too frequently" - and there's no clear way
to know when it's "too frequent" and the buffer overflows. The sample
code - TrackBot Common V2 - at java.net works pretty well, but not
100%. It gets flakier if you increase the serial polling rate, which
was the only clue we had until now.

We'll share any news as soon as we have more.

best regards

Bruce Boyes

If the human brain were so simple that we could understand it, we
would be so simple that we couldn't.  - Emerson Pugh, 1977