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.

TMS320F28379D: USB examples from C2000Ware events problems.

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE, CONTROLSUITE

Hello.

We are currently developing a system with a 28377D which will be able to connect by USB (CDC). In this moment we are testing with a 38379D control card (v1.3) on a  docking station. Power via dockstation with external JTAG.

I was just running a couple of examples from c2000ware:

...\device_support\f2837xd\examples\cpu1\usb_host_mouse

and

...\device_support\f2837xd\examples\cpu1\usb_dev_serial

In the mouse example, when I disconnect the device from the computer It receives a USB_EVENT_DISCONNECTED in the ControlHandler routine but in the serial example it does not. Also when I reconnect usb, mouse example receives a USB_EVENT_CONNECTED while seriel doesn't.

So mouse can restore its conection while seriel does not.

Is that a driver usblib bug ? Is there any workaround ?

Thanks

Samuel Ors

  • Are you able to send/receive serial communication via USB after reconnecting the PC with the device running usb_dev_serial example?

    sal
  • Hello Sal.

    I just re-checked what the example does.
    Writing on usb side outputs to serial side. Writing on serial side does not (it should, agreeing with the comment in the header).

    If I disconnect the serial side and reconnect it again it works as before disconnecting.

    If I disconnect the usb side and reconnect it again it works as before disconnecting.

    The problem I see is that there is a condition (that cannot be reproduced in this example because uart is not writing to usb) that will lock the transmission from the device to the host:

    The uart-rx to usb path is doing:

    USBUARTRXIntHandler(void)  ->
        ReadUARTData()
            if (USBBufferSpaceAvailable((tUSBBuffer *)&g_sTxBuffer))
                USBBufferWrite(...)

    That triggers the USB driver to send the data.
    But what happens if the usb is disconnected from the host ? Buffer will be full and USBBufferSpaceAvailable() will return 0, thus not sending any data.
    This should be managed in ControlHandler with USB_EVENT_CONNECTED (that calls to USBBufferFlush), but this point is only reached on the first connection (power up + connect the wire).
    Also USB_EVENT_DISCONNECTED is never reached.

    I checked this lock by modifing the example to be continuouly writing with USBBufferWrite(). While there is a conection it works, but it fail on the first reconnect.

    We want to achieve a continuous write from the device to the host while it is connected but we will have the buffer-full problem as long as there is no events
    related to the connection.

    I also checked that in the mouse example those events are being received in the MouseHandler() callback.

    Thanks,

    Samuel Ors.

  • Hi Samuel,

    Thanks for looking into this and detailing the behavior.

    I am working to see if we can get another engineer to look into this, due to the fact that I am the main support engineer for USB questions and am currently very busy. Hopefully, we can address your problem quickly. In either case, I will file a bug to be looked at in the future for this example.

    I agree, there does seem to be a bug since the UART to USB transfer is not being complete although I have had it working in the past.

    If the USB stays connected, the USB FIFO should not overflow. Are you seeing the buffer overflow even when the USB is connected and transmitting data?

    Do you have another specific question?

    sal
  • Hello Again.

    Indeed UART to USB was working, I setup the card correctly and now I've been able to send from the UART side.

    That allowed me to make this test:

      - From uart console, press some keys to see those in the other one (USB).

      - Then disconnect usb side a keep pressing a key for long time (I think 20 secs should do).

      - Reconnect USB and the console attached to it. 

      - Write on the usb side: showed in the uart side.

      - Write on the uart side: nothig shown in the usb side.

    Samuel Ors.

  • Samuel,

    Thanks for the test case. We will look into this before the next C2000Ware release.

    sal
  • Hello Sal.
    Thank you for your time.

    Is there any date already settled for next release ?

    Samuel Ors.
  • Hello

    I have exactly the same problem than Samuel Ors.

    Is problem solution was found?

    I'm using the control card F28377D.

    This is strange because I remember that I have already test the USB_dev_serial exemple with controlSuite v200 library on March 2017 and I think the flag g_USBConfigured was really well updated. But now, it is not the case (with CotnrolSuite v200 or C2000Ware v1.0.0.0) So now I'm not very sure this work fine some week ago..

     

  • Nobody has resolved this problem?

  • Not yet. We hope to get to it soon.

    Thank you.
    sal
  • Hello

    I hope also!

    I'm also trying to check the USB code in my side...

    Thank

  • Can you try this: On a disconnect clear the SOFTCONN bit and then set it again afterwards. This may help.

    sal

  • Hi,
    In my side, bellow is the manipulation I done. (I hope I well understand your request)

    - Board was started
    - USB cable was plug to the computer
    - Event Connected appears (My flag "UsbConnected' was set to 1)
    - I unplug the USB cable (No event UNCONNECTED...so my flag UsbConnected stay to 1)
    - By debugger, in the register view, UsbaRegs->USB_FADDR_POWER->USBFPOWER = 0x60.
    -> Set value by hand to 0x40 (Bit 6 clear to 0 => bit SOFTCONN) => Nothing append (No EVENT DISCONECTED...)
    -> Set value by hand to 0x60 (Bit 6 set to 1 => bit SOFTCONN) => Nothing append (No EVENT DISCONECTED...)

    I hope this help you.
    Thank
  • Hello

    Is my last post was help you to find the problem?

  • Hi,

    This seems to be a bug in the examples. This has been reported, and an engineer will address this in the future.

    Thank you,
    sal