Problem with CDC class device using Freescale USB stack version 4.1.1

[Symbolic]

We are building a project using the Freescale USB stack version 4.1.1

In this project, we are using the USB CDC class to create a virtual com device with the KInetis using the USB Device Stack (not host).

All seems to work well as long as a human is typing on the host (windows) terminal (Tera-term).

However, when we attempt to do a file transfer (using XMODEM) things just stop working.

(We have this working through a real serial interface - in the same project with compile time selection between a real RS-232 serial port and the CDC USB device)

Using the debugger, we have been able to determine that the Processor Expert generated code is delivering the same 16-byte packet (first packet of the XMODEM first block) over and over and over (endlessly).

The callback routine passed into USB_Class_CDC_Init() is the routine being given the same 16-byte packet, endlessly.

This continues even when the host program has stopped trying to send any data.

When human typing is involved, the packets are much less than 16 bytes.  When XMODEM starts, it triggers the reception of 16 byte packets, and then we hit this endless loop.

A short follow of the return path shows that the packet buffer points to itself as the next packet buffer.

We did not follow the code path any further.

[Symbolic]

Further data:

   Our application was not following the correct procedures.  And once it does, the problem goes away.

Further details - in case it helps someone else with similar issues:

  Our application (modeled on the "virtual com" example) was requesting additional receive data only after a send of data was complete.

  This worked in the "human at the terminal" situation, because we always echoed back whatever was typed on the command line, thus triggering more data reception.

  In the situation of the XMODEM transfer, we were not asking for more data to be received at the end of the first packet, and therefore no more data arrived until we NAK'ed the packet (due to timeout)

  Once we changed the code to request more data as a consequence of having *received* data, the issue resolved.

  However, we did note that the incoming data flow resembled "trying to drink from a firehose" and we had to make a buffer big enough to hold an entire XMODEM packet (and then a little) before we were able to get reliable data transfer.

It seems that with a "virtual COM" on both ends of a CDC connection, the baud rate has little or no meaning!