Hi all...

First of all, this is the first time I really try to implement a USB connec=
tion
from both sides, i.e. from the PIC and from the PC side. I looked around a =
lot
and found the m-stack usb stack which seemed quite easy-to-use.=20
(see http://www.signal11.us/oss/m-stack/)

I took part of the PIC demo code provided, and part of a PC-side C program =
and
modified them to only do Control Transfers. In the PIC, I received a byte w=
hich
controls 4 LEDs, and in the PC program I simply call it with 1-4 as paramet=
er
to switch one LED on.

Everything works perfect. Except that after about 120 seconds, the LED swit=
ches
off without any action on my part. The pic program still runs, and I can sw=
itch
the LED back on...

I traced the USB connection in Wireshark, and found that coinciding with th=
e
off-switching of the LEDs, there is a sizeable block of communication from =
the
PC on the bus. It starts with an URB_INTERRUPT, then GET_STATUS, CLEAR_FEAT=
URE
and a load of other GET_STATUS packets. Particularly worrysome are=20
GET_DESCRIPTOR_REQUEST, which get malformed packets as reply.

My question(s): 1) What is this perioding 'polling' from the PC to the devi=
ces?
I can't seem to find any reference to this in the USB specs. It seems to ha=
ppen
every 2 minutes or so.

2) What is the effect of a malformed packet in USB?

3) Anyone with experience with the m-stack?

Cheers,
John
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.