Hi everybody.
I'm working with C# framework and I'm basing my firmware from the secure USB time-stamp firmware to learn how to comunicate through Usb.
I've made my own board using a PIC 18F14K50 so I've changed the library to get the device working, and it seems to work.
The first command read 8 numbers from the device and the computer shows them in textbox.
The second command simply lights up a LED.
Once I send the first command it works, then i send the second command and it woks again but the problem appear when I try one more time to get the numbers, The program freeze a few seconds and then it tells the device is disconnected!
I have the same problem when I try to get numbes two times below or when I try to lights up led twice.
How it's possible?

(sorry for my english i hope to have explained well the problem)

If the host library pauses and then disconnects the device it is because the host is not receiving the expected response from the device (not enough bytes were sent by the firmware against what the host was expecting to receive. So you most likely have a bug in you host device code or the firmware which responds to the commands. If you watch the debug log output from the C# library in visual studio it should give you some clues.

how to this can be avoid if the host send command to PIC to reply since the pic is busy. i m using c++. The VS at the output column it say that system.threading.threadexception? how can i catch this error. because i wan the application contiune to run

Hi, you can't avoid this is USB Generic HID, the PIC must always be ready to reply and therefore the PIC's USB stack must be continuously polled by the firmware or the USB communication will fail at the driver level in Windows.

If your code/device needs a long time to respond it must respond to incoming commands with something that tells the host it is not ready so the host knows to keep trying. If you can't make your code compatible with polling then you can set the USB stack (on the PIC) to use interrupts so the poll continues in the background whilst your code is working.

Since, in USB Generic HID, all communication is initiated by the host, the firmware must always be ready to accept incoming commands and send any appropriate responses. You can, of course, use other USB protocols if this is too much of a limitation, but then you will need custom window drivers too (so the work is much greater).

iccc, so i need write an interrupt rountine for handle the USB communication, just simply move the IOProcess() into the interrupt rountine then the problem is solved. m i right?

The firmware is already set up to work with interrupts rather than polling, you simply need to set the correct #define statement and remove the polling loop. Since the firmware is based on the microchip stack there should be guidance on how to do this via google (I don't have the source code to hand at the moment, so I can't be too specific - but it is in one of the configuration header (.h) files).

icc thx again~