Tivaware serial CDC drivers install nonfunctional com ports named Tivaware COMx & bus faults occur.

Hi Amit,
Yes that is what made both COM4/5 transport stop data flow after updating the COM ports drivers to the new Tivaware Serial CDC in device manager. The installer is not installing lmusb*64.dll's in System32 folder. I assume the amd64 device driver folder is for Win7/64bit and the 32bit USB drivers should not be there?

Will try to remove the ICID USB package completely and install the new version but how to make it select 64bit drivers?

The windows serial port driver is still not transporting data after installing Tivaware ( 2. 1.2.111) serial port driver or serial command port neither one works. The Stellaris emulation package ICDI DFU update link CCS5.4 updates stop 8/3/2012 (2.09270.0).  There are no newer emulation package updates: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/CCSv5.1/Updates/Emulation/win32/full. Changing the URL CCSv5.4 returns error no such folder. 

Recall past having to monkey around with other packages to get the USB virtual serial COM to work. Windows drivers folder (usb_dev_serial.inf) device listing does not specify the Serial Port being Virtual like Stellaris driver past did. Not sure that is important but it is not being consistent with established naming conventions and confuses the situation.  So it (Tiva COM driver)  seems to be virtual but that is only a guess and everything is installed but the Virtual COM ports still don't work and have no Warnings of failure.

Any one of the installer *.inf can not find an updated 64 bit composite driver. Could be why the updated virtual serial port device is not working with the older composite version.

Hi Amit,

The point being presented; Updating existing (2.1.0.12573) Working virtual serial devices with windows drivers (2.1.2.111) broke both COM4/5 virtual serial ports.

Windows System information shows both updated virtual serial ports present and functional. Virtual connection state (serial command or serial driver) toggles when the client terminal is connected/disconnected but no data is being passed from the ICDI driver into the USB virtual serial port.

Hi Amit,

Making calls to  UARTprintf() with compile symbol (UART_BUFFERED) 2 launch pads. The ICDI virtual COM4/5 enumerate in the Windows client terminals yet no data will pass. They were passing data until and after updating newer Windows serial drivers. The enumerated serial ports vanish when ever the ICDI USB cable is unplugged, indicates the pipe is being created.

Are virtual serial drivers found in (USB_Dev_Serial.inf) -- the word (Virtual) is missing in the device list details for any single serial port driver name? The original working Stellaris virtual serial port drivers showed up in the device manager, made it unquestionable the driver installed was indeed a virtual COM port. Rolling back to the Stellaris virtual serial driver does not fix the problem.

  
// Enable pin PA0, PA1 for UART0 U0RX, U0TX
ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
ROM_GPIOPinTypeUART(GPIO_PORTA_AHB_BASE, GPIO_PIN_0 | GPIO_PIN_1);

// Enable the UART, clear the terminal.
UARTStdioConfig(0, 115200, g_ui32SysClock);

/* Report that we found an IP address. */
UARTprintf("IP Address Found.\n");

Hi Petrei,

Had forgotten the hidden non persistent devices don't necessarily show up even when unhidden via pull down. Wish it were that simple in this case thanks for reminder. Now the WIN7 ports advanced choice dialog allow us to force in use COM ports as the current device. Perhaps MS got some complaints that issue and added ability.

This virtual serial COM was hard to get working as I recall 2 years ago fought similar issue. The Stellaris virtual COM driver once again matches the ICDI/DFU driver version & date 2012. There seemingly are no further ICID updates for CCS5 after 2012.

Have confirmed UART0 TX data is captured via oscilloscope on JP5 just prior to ICID.

That said two new EK-TM4C1294XL launch pads are transmitting UART0 data on the very same COM ports.

So it seems 1 of 2 older launch pads UART0 or the TM4C123G ICDI internal SW driver is failing for what ever reason. 

Hi Petri,

The hidden devices were still there even though Win7 removed INUSE status from previous orphaned virtual serial ports.

The syntax of posted command spaces between (devices = 1) was not showing the hidden devices. Every one previously  removed INUSE status was still there in device manager. Thank Microsoft for lazy programming show hidden devices still is not working from a user perspective.

That was one issue and the other: 1 of the 2 connected EK-TM4C1294XL ICDI stopped working. There is UART0 data being sent to ICDI and it enumerates a COM port when USB is plugged in but does not pass the data to Windows.

LMFlash build 1613 is showing ICDI build 12630 - how to update/replace the ICDI build?

Hi Amit,

Seem to recall seeing something like that but how to search for links by name Tsuneo Chenzei?

That's just the point the ICDI was manually shut (radio button) from the terminal prior to disconnect and reconnect. The terminal emulator scans Windows for in use com ports and refuses to reconnect if it is in use so we know when that has occurred.

We shouldn't have to power cycle the launch pad since Windows driver detected the virtual com port disconnect. It seems the ICDI virtual driver sometimes does not know his USB cable was forced to a disconnected state since he still has power?

In above posted the launch pad had been power cycled many times without ICDI connection and still refused to send TX data to the virtual USB host. The flux remover fixed that issue and it has been ok over several disconnects. So if 2 comports are active and we want to LMFP one the other has to be unplugged every single time. Perhaps LMFP needs to evolve detecting all ICDI USB devices and allow user to select witch one to flash since it won't auto rotate the index to the next connection.

BTW: The USB index lookup function in dfulib wrapper only detects/reports ICID connected devices and skips connected OTG ports where the serial boot loader would seemingly exist.

The one difference is the ICDI is being powered by the OTG +5v0 source.