I am using Windows 7 in a virtual machine on Macintosh. This issue may be fixed in the Windows 10 driver. However, Windows 10 is not allowed at our company due, in part, to the keylogger (see this report from PCWorld ), and other data logging features that leaks proprietary information back to Microsoft. Only the enterprise edition can turn off all the data loggers. Microsoft has a very long page on accomplishing this, if you are interested.
As many of you know, when you plug in a CY8CKIT-059 on the debugger stub side, you get a serial port (a USBUART) that is connected to P12.6 and P12.7 on the target portion of the CY8CKIT-059. You can use a terminal program like TeraTerm or Putty and print messages using a UART in your project connected to those pins.
If the VM is rebooted, and the KitProg is connected, the USBUART generally works. It also typically shows the USBUART in the list of USB devices available to attach to the VM in VMWare's list. If you unplug and replug the KitProg, the USBUART driver shows up in the Com Port section (i.e. COM Port 46), and the terminal programs connect to it, but no serial data. The KitProg debugger continues to work.
If you disconnect the KitProg from the VM, then the Macintosh shows the USBUART like so:
The tty.usbmodem1423 is the Cypress USBUART. The tty.usbserial-A600esPZ is an FTDI chip plugged into the Macintosh. It works fine with windows or Mac. No issues.
By running the "screen" program on the macintosh, I get a USBUART connection that works:
screen /dev/tty.usbmodem1423 115200
The screen program connects and communicates with the USBUART running on the KitProg just fine. So, the problem does not appear to be with the code on the debugger stub, but either with the Windows Driver or how VMWare sees the USB device and hands it back to Windows. Looking at the details on the windows driver (under right click on Computer: choose Manage: choose Device Manager, everything looks good. Running the Bridge Control Panel shows the driver (i.e. COM46); it also connects and disconnects to that port, but still no data gets through when restarting, disconnecting and reconnecting with the port using Tera Term or Putty.
I have the latest downloaded from Cypress, PSOC Programmer 3.28.6, and everything else is working just fine. I noticed this problem a few months ago, right after the CMSIS code was put in, but had too much going on for it to bother me.
I have also seen this when creating a USBUART using Vendor ID 0x4b4 and Product ID 3, 5, or 8 during engineering builds to test my PSOC code. Linux and Macintosh work fine, Windows usually works after a fresh reboot, but rarely after that, after a plug/replug. No driver errors reported. I have fixed the Cypress example USB code to prevent hanging in my application. (works for Linux and Mac). I have *not* touched the KitProg code, which is proprietary. I have *not* used my USBUART code when the KitProg USBUART fails. It will fail even if I *never* plug in my USBUART, and I have rebooted my machine to get a fresh driver loaded to troubleshoot this issue.
Any suggestions? I have followed the previous threads int the community and reloaded drivers, etc, but no luck so far.
That did not work with 0x4b4 and 3 as USBUART parameters. After 4 hours of installing, removing, rebooting, uninstalling, following different suggestions on the internet, with nothing from the Cypress community or internet at large working, I decided to uninstall and delete the drivers and reboot (without devices plugged in).
I went back to the USBUART and deleted USBUART, and put it back into the Schematic. I rebuilt. I plugged in the Kitprog, and all the drivers had to be re-installed. They installed successfully.
I then plugged in the USBUART and interrupted its install from Windows Update. I pointed it to the driver file in the PSOC directory: ProjectName.cysdn\Generated_Source\PSOC5 and installed that unsigned driver (under windows 7).
Now, the KitProg USBUART shows up in the serial port list, and the new USBUART shows up. I connected to it with Tera Term Pro, and the system does not lock up now.
One problem I saw, was if you use USBUART_PutString(string), there is a problem with multiple calls before the packet is transmitted. I solved this on my side with a simple delay to accommodate one line of text being printed at a time at 115,200 baud. I'm sure there is a better way to fix this, but this works in this application for me.
Here is my function which wraps the USBUART_PutString()