• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 419 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TM4C1237H6PM: Run-time DFU on CDC class device

TM4C1237H6PM: Using CDC class USB driver without UART

Dhammika Wijesundera
Intellectual 645 points
Part Number: TM4C1237H6PM


Hi,

I modified your example, usb_dev_serial to run without the UART. My program just echos back whatever I type on the serial terminal. I have attached the complete program below. I have the following questions.

I handle the event, USB_EVENT_DATA_REMAINING in the RxHandler just by returning 0 as follows. Is that OK?

        // We are being asked how much unprocessed data we have still to
        // process. We send 0 if USB Tx buffer can take data
        case USB_EVENT_DATA_REMAINING:
        {
            return(0);
        }

In the ControlHandler, I handle multiple events by ignoring them (see below). These were handling UART events in the example code.

        case USBD_CDC_EVENT_GET_LINE_CODING:
        case USBD_CDC_EVENT_SET_LINE_CODING:
        case USBD_CDC_EVENT_SET_CONTROL_LINE_STATE:
            break;


        case USB_EVENT_DATA_REMAINING:
        {
            return(0);
        }

Thank you,

Dhammika4834.usb_dev_serial_without_UART.zip

  • 0
    TI__Guru*** 135355 points

    Hello Dhammika,

    Those are really application specific concerns. If you won't be receiving data then you don't need to process that event. The CDC events are usually part of the enumeration but may not be required.

    I wouldn't say that's the typical implementation but as long as it works for your purposes, it wouldn't cause a library error unless you don't process the RX data quick enough and lose track of how much buffer space you need to clear etc.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Intellectual 645 points

    Hi Ralph,

    Thanks for the quick reply.

    Returning 0 for the USB_EVENT_DATA_REMAINING event has worked for me all the time. However, I found in the morning today that the events,  USBD_CDC_EVENT_GET_LINE_CODING and USBD_CDC_EVENT_SET_LINE_CODING need to be handled properly. That is  we must return 1 for the event USBD_CDC_EVENT_SET_LINE_CODING and we have to populate the pvMsgData input/output of the USB control callback with some values. Please confirm this on your end.

    Thanks,

    Dhammika

  • +1 in reply to Dhammika Wijesundera
    TI__Guru*** 135355 points

    Hello Dhammika,

    That makes sense to me based on how our Windows drivers are setup for enumeration for a CDC device. I was a little surprised that it was working without those honestly.

    The idea with those commands is it helps set the COM Port baud rate and data size etc. so its not really tied to UART though the demo might make you think that because those are usually tied with UART - but you are using the same terminal as a UART connection for the USB COM port so the same settings apply.

    There may be ways to avoid needing that via the USB driver but I am not 100% sure.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Intellectual 645 points

    Hi Ralph,

    Thanks again for the quick reply. I have specified the parity, no of bits and no of stop bits using USBD_CDC_EVENT_GET_LINE_CODING . I did not define the baud rate though. 

     

    Then I ignore the USBD_CDC_EVENT_SET_LINE_CODING  event. That seems to work fine. 

    I can specify any baud rate when I make the serial connection. It seems CAD drivers have a mechanism to detect the baud rate automatically. 

    Thanks,

    Dhammika

  • 0 in reply to Dhammika Wijesundera
    Intellectual 645 points

    Hi Ralph,

    I changed even things like parity and no of stop bits during serial connection is made. Even with those changes, it works. It seems CDC drivers are capable of identifying everything before communications start.

    Thanks,

    Dhammika