USB CDC Fails (after many successful transactions) [Processor Expert]

[atm]

Background:

I am working on a project that uses the USB CDC processor expert component for a K60. One of the things I am using the CDC for is to transmit firmware data to the microcontroller that it uses to update itself (once it has been saved to some external memory). I also have a C# app transmitting this data over the Virtual Com port (that is the CDC). The data is in Intel hex format, and the (sort of naive) implementation I am using transmits the data line by line, waiting for a character ack or nack after each line.

Sad Story:

After making some significant code changes (including more computation in interrupts with higher priority than USB), the transfers started failing. They used to work earlier in the development. The entire transfer of data takes a little while, and it now fails sometime during the transfer (Somewhere between 1% and 99% of the data). Typically, when it fails, the C# app has a WriteTimeout. If I look at the USB IRQ (after entering the error state), I am still getting interrupts with the SOF flag, but I never get the TOKDNE flag set (despite the fact the C# app is trying over and over). Also, I don't see any USB error flags set if I break on entering the ISR. So I am trying to diagnose what is happening with the USB that could cause it to go into a state where it no longer responds allows USB transfers to occur.

Without a doubt, I am a USB novice, so I despite reading about it, I am not sure I have a handle on the many things that must occur for writes from the host to occur successfully. It is a possibility that the target board does something to displease the host and so what the packet captures are telling me is getting sent never really ends up on the wires. I have used a few different USB capture tools while troubleshooting the problem, and one gives a status message like:

Any insights? Any things I should try? I will appreciate any suggestions!

[atm]

I have not completely solved this problem yet, but the problem nearly went away completely by making the USB ISR a higher priority. It is almost certainly a problem with excessive execution time of other higher priority interrupts.

I would still like to know how the USB code could detect the issue and resolve it.

[BlackNight]

Hi atm,

if you are not serving the USB application 'task' frequently enough, your USB communication will fail. So your statement that it goes better or solves your problem if you are using a higher USB interrupt level confirms this. If the device is not able to accept the USB packet in a timely manner, communication with the host will fail, as the host will see a timeout. But it means as well that your microcontroller needs to have enough bandwidth to process the packets received with the USB interrupt, otherwise the internal buffers will not be served, and again communication will fail.

Bottom line is: in order to have the communication not to fail, your microcontroller needs to have enough bandwidth to serve the incoming (and outgoing) USB packets, otherwise your USB CDC connection will timeout.

I hope this helps,

Erich

[marek_neuzil]

Hello,

Please, could you comfirm which component are you using? Do you use components from the Freescale USB stack or from mcuoneclipse.com website?

Best Regards,

Marek Neuzil

[atm]

I am nearly certain it is a component from the mcuoneclipse.com. It was added (not by me) to the project at some point and then we removed processor expert from the project. The output of the processor expert code shows:

**    Component  : FSL_USB_CDC_Device

**    Version    : Component 01.028, Driver 01.00, CPU db: 3.00.000

and

**     Component   : Init_USB_OTG

**     Version     : Component 01.004, Driver 01.04, CPU db: 3.00.000

in the file comment headers of CDC1.c and USB0.c, respectively. Is there a way I could better determine which source it came from?

[BlackNight]

Yes, based on the component name, the component is from mcuoneclipse.com. You can see this from the copyright section (at the end of the header you looked at).

Erich