• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 1464 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.

TM4C1294NCPDT: virtual COM port driver instable

Ruud den Bekker
Prodigy 210 points
Part Number: TM4C1294NCPDT


L.S.,

I'm currently testing the TM4C1294NCPDT launchpad board in combination with Simulink code generation.

We need a high speed serial interface from the board to the PC to catch measurements at high speeds.

The Virtual COMport driver is using the Wndows usbser.sys driver which is very buggy (enough URL to be found

on the internet), specially when the interface is running at high speeds.

I'm sending information at 912600 baud at 60 kBytes/second.  After about 0.25 seconds the driver reads

wrong data from the port. An more than 10 year old EM1016 Serial-USB driver does not have this problem.

I can go up to 80 kByte/second and beyond and communication will not get lost.

Is there another driver available for the Stellaris Virtual Port?

  • 0
    Genius 3850 points

    There  could be countless reasons other than a buggy driver that contribute to your problem. Unless you can narrow it down to the driver, finding an alternate driver may not be that helpful in solving your problem.

    With that kind of high rate, other means, like a spi or USB bridge, should be considered.

  • 0
    TI__Guru**** 191906 points
    Hi Ruud,
    As you already know the usbser.sys is automatically loaded by MS Windows as the driver to interface with CDC class devices. Do you have the same problem with Windows 10 and Windows 7?
  • 0 in reply to Charles Tsai
    Prodigy 210 points
    Hi Charles,

    Since I don't have Windows 10 PC, I'm not able to test this.
    I bought a FTDI232RL board and this works flawlessly at 3MBaud.
    So the driver definitely is the problem.

    Regards,

    Ruud
  • 0 in reply to Ruud den Bekker
    TI__Guru**** 191906 points
    Hi Ruud,
    Glad that you find solution with the FTDI chip and its driver. Just curious what was on your original board to support the USB virtual COM port. Did you have the FTDI already before? Or you were using the LaunchPad?
  • 0 in reply to Charles Tsai
    Prodigy 210 points
    Hi Charles,

    I simply used the launchpad serial interface/JTAG combination over USB.
    I also tested with an more than 10 years old EM1016 serial-to-USB converter that also worked perfectly until 1MBaud.

    Regards,

    Ruud
  • 0 in reply to Ruud den Bekker
    TI__Guru**** 191906 points
    Hi Ruud,
    In the LaunchPad, the TM4C129's UART0 is connected to another TM4C123 processor acting as a debug probe as well as handling the USB Virtual COM port. When you add a FTDI, are you creating you own board or you just use another UART port like UART1 or UART2 or etc?
  • 0 in reply to Charles Tsai
    Prodigy 210 points
    Hi Charles,

    Of course, I'm not using the TM4C123 processor in this case.

    I removed the jumpers to the TM4C123's RX/TX lines and connected my
    FTDI board to those pins (A0/A1).

    Regards,

    Ruud
  • 0 in reply to Ruud den Bekker
    Guru 117855 points

    Interesting report - yet would you be so good as to confirm that you've:

    • employed an FTDI  "UART<->USB" conversion board
    • and added a software driver provided by FTDI and bypassed or disabled the T.I. driver

    Is it possible for you to examine the performance of the FTDI implementation - but using the "original - T.I. software driver?"     Does the data rate "slow" - as you expect?

    And then - for completeness - what results when you employ your "'129 board thru the '123" (serving as ICDI) - yet using the FTDI software driver.    Does the data rate "increase?"

    (in both cases - it is "assumed" (really hoped) that the "driver" proves "device agnostic" (so that this experiment has some chance - to run/work)     It is unknown (by me) if such "agnostic acceptance" proves the case...)

  • 0 in reply to cb1_mobile
    Prodigy 210 points
    Yes, I

    - employed an FTDI "UART<->USB" conversion board
    - used the FTDI driver that was automatically installed after plugging in the FTDI device.

    I could try what you're asking for, but how should I do this? Since the USB device is being detected
    (using VID:PID id's I assume), how can I use e.g. the FTDI driver in combination with 123 processor?
  • 0 in reply to Ruud den Bekker
    Guru 117855 points

    Thank you. Indeed - I've pretty much left the, "Heavy Lifting" to you...   (in my defense - we don't have your FTDI board (yet).

    Perhaps this (may) work as a "quick/dirty" test "fix." (quick/dirty - my favorites...)     Might you "copy & safely store" the "VID:PID" of the drivers (and any other "similar" vendor data - I am HOPING that this is minimal) and then simply "alter that VID:PID data" - simply for the purpose of experimentation.    (as I've been to law-school - NO/ZERO official or carry-on use is directed nor intended.)

    The objective is to attempt to discover if an "eased mechanism" may be discovered - which boosts the performance of this vendor's USB driver - nothing more - nothing less.

    Oh ...  if not too obnoxious - might you be good enough to briefly describe your "experimental method of determining the 3Mbaud data rate" - achieved via the FTDI device?     Of high interest is the, "Size of the data packet passed - along w/your means of determining the "duration" of the active transfer.    Indeed this places "extra effort" upon you - yet this forum is active enough that others may be motivated to comment - and if we're especially lucky - may be able to suggest (other) and/or (improved) measurement methods.

    Firm/I have a "Belkin" UART<->USB converter - and will add to your findings w/our report.    (the chip w/in the Belkin is (thus far) unknown)

    Thanks for your great cooperation and for reporting your findings - sure to be helpful to so many - here...

  • 0 in reply to cb1_mobile
    Prodigy 210 points
    Ok, I'll do some testing with the driuvers, but give me some time.

    To give you an idea: maximum tested runtime is 20 seconds now, using the TM4C1294 serial FIFO only,
    8 bytes per "packet" @ 10.000 packets/second using simulink model generated code. Data is being collected using
    a custom simulink block and sent to a scope and workspace.

    FTDI stands like a rock. Depending on the chip being used, maximum speed is 1MBaud or 3MBaud.

    to be continued.
  • 0 in reply to Ruud den Bekker
    Guru 117855 points

    Ruud den Bekker said:
    FTDI stands like a rock

    As do you my friend - as do you!       Simply terrific cooperation - thank you - know that your efforts (especially your detailed descriptions) are much appreciated.

    I'm wondering about the, "Custom Simulink block" - how well or even if - that "block" meshes efficiently w/vendor's USB implementation.     (completeness seeks the "coverage of all bases.")

    It is hoped that some (finding) yields a method  to "enhance" this vendor's USB driver - to the benefit of all here.       It is my belief that, "Purpose Developed, Commercial Implementations" - "Lead the Pack" - and there may be, "helpful facts to be gleaned" - resulting from such tech. examinations...      Again - great thanks for all of your efforts - generous & inspired...