This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28069U CDC Device COM port lock-up

Other Parts Discussed in Thread: CONTROLSUITE

Hi,

I am developing a motor controller with the F28069U.  Almost everything is working perfectly.  I am controlling two separate 5-phase stepper motors, using timers to control stepping speed.  I have two means of communicating with the controller: SCI, and USB.  For USB I am using the F2806x USB Library from controlSUITE v135.  I have a Windows app that connects to either serial or USB (which is configured as CDC device, and appears in Windows as a COM port).  My Windows app communicates with the controller using a series of short commands (less than around 32 bytes each), waiting for a response from the controller after each command before sending the next command.   When using USB, the Windows app eventually locks up, deep in the bowels of the USB device driver and I must kill the process.  The USB COM port stays in the locked up state until I power cycle the piccolo controller.  However, the rest of my application on the controller continues to run just fine, and I can even reconnect my Windows app to it over the SCI COM port and it will continue to run as if everything is just fine.

The other issue I have is that when connected with USB, the interrupt handling for USB seems to be eating up enough processor time that I can hear my steppers pausing periodically when my Windows app is communicating, presumably because the USB interrupt handler is taking a very long time to return and thus delaying my timer interrupts for quite a long time.

Any ideas why my USB would be locking up?  Any advice on how to debug this?  I was hoping not to have to understand the innards of the USB Library.

Thanks,

Angelo

  • Angelo,

    I am working directly with your FAE to resolve this issue.  Please stand by for a solution to follow shortly.

    Regards,

  • Trey,

    Here is my latest info (also just sent to FAE):

    The protocol we are using for this controller is a simple command line style protocol, intended to allow use of the controller from a simple terminal emulator connected via either serial or USB (as a CDC class device).  As such the controller echoes each character received to give the feel of an actual command shell.  What I see in the protocol analyzer is that each time the failure occurs:
    1) The PC sends a command line (e.g. "read 20\n")
    2) The controller echoes only part of this command (e.g. "r")
    3) The PC times out attempting to read the echoed command after 0.5 seconds.
    4) The PC tries again, sending another command, which is acked by the controller (but never echoed).
    5) Neither side transmits anything after this point.
    I can see in the JTAG debugger that the full echo string from the command in step #1 was indeed written to the USB transmit buffer in RAM by our parsing code, but only part of it made it out onto the wire.  So, it appears that something goes wrong with the transmit (IN) endpoint prior to the receive (OUT) endpoint.  Neither endpoint generates any interrupts after this point, even though I can see that interrupt status bits appear to be set using the debugger.
    Thanks,
    Angelo
  • Trey,

    What is the status of this problem?  I need an outlook for a solution that I can pass along to our customer.

    Thanks,

    Angelo

  • Angelo,

    I've been out of town since Thursday of last week and have just gotten back to the office.  I'm getting caught up and hope to have some time to look at this tomorrow.

    Regards,