Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm transmitting a buffer array from inbuilt USB of PIC 18F controllers and sending this to a GUI. I am able to detect the device properly (enumeration). But the GUI crashes some times, without any reason.

I assume it is a transmission/interrupt problem as whenever I'm sending a constant number it does not crash. But whenever I'm doing an ADC operation and sending the corresponding value via USB, it crashes.

This made up my assumption that USB transmission or interrupt handling needs to be handled properly.

I'm new to the USB protocol and tried with this working code.

I have no problem regarding enumeration, but when transmits the crashing occurs.

The format of the code is:

{   usbinit(); // usb initialization


      UsbTasks(); // does usb works    
      yourtasks();//sends the buffer 



I would like to understand what might be the cause behind this anomalous behavior.

As noted below in the comments the USB stack is set for polled configuration. How should I manage the ADC read?

If I do:



          UsbTasks(); // does usb works
          yourtasks();//sends the buffer 


Will it make any change? Or is this not the best way to send ADC values?

share|improve this question
Do you have the stack set for polled or interrupt mode? If it's in polled mode the ADC read is probably stalling the call to UsbTasks for too long. – PeterJ Feb 12 '14 at 6:46
Thanks a lot @PeterJ I have to check that.I'm browsing through the code right now. – Rookie91 Feb 12 '14 at 7:13
If the GUI on the PC crashes that sounds like a software problem, not an electronics one. – David Feb 12 '14 at 7:41
Thank you @David. – Rookie91 Feb 12 '14 at 9:53
@PeterJ The stack is set for polled configuration. How should i manage the adcread then. – Rookie91 Feb 12 '14 at 9:54
up vote 4 down vote accepted

According to the USB CDC Class on an Embedded Device application note by Microchip which would mostly apply to other device classes as well:

The USBTasks routine may be used in a polled, cooperative manner as demonstrated. If so, nothing in the main loop should block for more than a few microseconds or events may be lost.

So the main two solutions that come to mind are:

  • Rather than wait for the ADC conversion to finish start the conversion and then use a conversion complete interrupt so that the main processing loop can continue while the ADC is taking a sample.

  • Set the USB stack to use the interrupt-driven mode to remove the requirements to call UsbTasks so often.

For most applications I'd say the latter is probably the easier solution so you don't have to worry so much if your main loop stalls a little while.

share|improve this answer
Thank you very much .@PeterJ – Rookie91 Feb 12 '14 at 10:42
adc conversion will take some microseconds i trust :). Could that be also a problem. – Rookie91 Feb 12 '14 at 12:25
It depends on the part and ADC setup, but I think the typical fastest speed for most PIC18 parts is around 100ksps, so that would be 10us. – PeterJ Feb 12 '14 at 12:35
That Won't cause any problem hopefully right :) – Rookie91 Feb 12 '14 at 12:41
The Microchip docs do say a 'few' microseconds which while not precise I'd interpret as two or three, maybe a little more so it could well do. There can also be some disavantages to running an ADC at the maximum rate so you'd really be best to avoid reading it in the polled mode and either use interrupts for the USB or ADC side. – PeterJ Feb 12 '14 at 12:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.