USB interface communication issue.

G

GarrinC

Junior Member
Take 2. The first post was deleted during review for some reason.


Ok Apple Guys (or just smart guys in general) I need some help. I have purchased an automotive tuning interface from HP Tuners ( HPTUNERS.COM ) and am just hitting a brick wall getting it to work correctly on my setup. Several automotive tuners have this setup or a very similar setup that functions perfectly, so I know it can be done. I'm sure it's a very simple issue that I am overlooking but I am stumped and hopefully one of you fellow Apple users can help me out. I've searched for days, I even emailed HPT support not expecting a miricle since I knew going into this I was gonna be on my own trying to use an "unsupported platform", as expected they did indeed tell me to go pound sand, which is fine - It was worth a shot.

I installed the VCM suite (stable & beta EDITOR & SCANNER), installed the MPVI2 drivers from the website, did the authentication/verification process to get it added to my HPT account on their website, and everything was perfect... Next I click on the 'resync interface' and the window pops up for syncing - below of the information for what syncing does it displays the status and the progress bar it quickly starts with "READING FROM MPVI INTERFACE", as the progress bar speedily swipes left to right it changes to "SUBMITTING RAQUEST TO HP TUNERS SERVERS", then states "FAILED TO WRITE DATA TO INTERFACE" and the START button changes to RETRY and I can close the window or retry (which yields the same result).


I was able to get this to work on my windows laptop with no problems (ironically the same machine I used for the disk image used for the ISO when I set up my Macbook Pro back in 2018). So I began to dissect the differences between the two machines and the only thing I can find different is the handling of the data during data transfer to the MPVI2+. I used a program that I got for free (trial) called Serial Port Monitor (https://tinyurl.com/u2p4upfc) to monitor the communication as it happens in an attempt to diagnose the issue... which I think I did, but i'm not sure what exactly it means or how to rectify the issue. I will be hosting the 2 HTML files ( https://tinyurl.com/4nn8asuc & https://bit.ly/3Fo4ngw ) showing the data as sent from my macbook AND the working Windows laptop as well (Click the links and open then save them and open them them with a web-browser to view in tabled format (firefox worked best for me)) If you just click on the links they raw text will be displayed with is incredibly hard to read, trust me.... open with firefox or similar. It appears to me that it fails an authentication sequence, hence the "Invalid RSA key" statement located on line 1270 of the "failed dump.html", but i don't know how to decipher any more of the information to determine the needed fix. This may not be the entire (or even part of) issue I am having but it sure seems like it would be to me.

Here's my setup:
2018 Macbook Pro w/ macOS12 Monterey Running Parallels 17.01 w/ Windows10 (downgraded from Parallels 17.10 to resolve a usb connection issue).
view
view
view


I have:
Uninstalled/reinstalled the VCM suite
Deleted/reinstalled the drivers
Updated, then downgraded parallels (from 16.xx to 17.10, then down to 17.01)
I have run all Microsoft updates available
Upgraded to macOS12 Monterey... it didn't work with Big Sur either.
Tried several data cables between MPVI2+ and Macbook (with and without dongles)

UPDATE: I also installed another VM instance with a fresh downloaded of WIN10 from Microsoft to make sure it was not a hanging driver file of something that was causing an issue. Same problem with a fresh install, which tells me it's one of two things... The Mac side of things is interfering with communications or Parallels isn't handling the traffic correctly or isn't handling the driver correctly.

Here is the debug dump file from the application as well.
view
 
I had a similar issue with a serial device, when I went to 17.1. Downgrading seemed to fix the issue based on https://kb.parallels.com/en/128608 although I missed a step the first time. I saved my VM before I did the upgrade to 17.1 and had to pull it back after doing the downgrade to 17.0.1 to get it to work. I lost a week or two of updates I did to that VM but it fixed the problem. Not sure if this would apply to you, but it was the only way after a day of troublehooting i could get it to work. I also subscribed to updates on that KB article, it's pretty clear they will need to fix that as 17.1.0 seems to screw up the USB comms for many of us, and that's not something that can be an "oh-well".
 
RichR2 said:
I had a similar issue with a serial device, when I went to 17.1. Downgrading seemed to fix the issue based on https://kb.parallels.com/en/128608 although I missed a step the first time. I saved my VM before I did the upgrade to 17.1 and had to pull it back after doing the downgrade to 17.0.1 to get it to work. I lost a week or two of updates I did to that VM but it fixed the problem. Not sure if this would apply to you, but it was the only way after a day of troublehooting i could get it to work. I also subscribed to updates on that KB article, it's pretty clear they will need to fix that as 17.1.0 seems to screw up the USB comms for many of us, and that's not something that can be an "oh-well".
Click to expand...


Thanks for taking the time to lend a hand. I went back and performed the procedure again and confirmed that I'm running 17.01 (rather than 17.10), unfortunately nothing has changed. But, I do still think it's a parallels issue mores than anything else. I can see that the MPVI2+ interface is recognized by the MacBook, the parallels pop-up appears when plugging the MPVI2+ interface in and forces me to select which OS I want to tether the device to. If I select macOS then the instance of Windows acts as if it's not there and when I select Windows10 it shows up in the Device Manager and HP Tuners sees the interface when I go to sync it, but it fails to write to the device. From the traffic dumps of the device - I suspect its the way parallels is handling the driver but I'm no engineer by any means. I have uninstalled and reinstalled the driver several times. both on my MacBook and on a Windows laptop and it runs fine on the windows machine & for the life of me I can't spot a difference between the two.
 
I have a similar issue - something I use once every 2 months or so has stopped working. Its a USB to RS232 converter with an interface to OMRON PLC' - I would guess the mechanism of how this communicates is the same as your MPVI2+ interface. This has worked OK in Windows 7 and Windows 10 for years for me. The USB port is all there in Windows - it just won't communicate. I tried 2 VM's - both the same. Either the latest Parallels V17 has bricked it or the Combination of that and MacOS Monterey has stopped it working.I got around it today using a Windows laptop. I am hoping an update fixes it
 
UPDATE: I have found that Microsoft logs drivers issues during attempted installations (passed or failed) in what they call the Event Viewer which is included in Windows10. I have observed my log and its states:

"Driver Management has concluded the process to add Service usbser for Device Instance ID USB\VID_31DE&PID_1860\5&19F4C0D2&0&6 with the following status: 0."
"Device USB\VID_31DE&PID_1860\5&19f4c0d2&0&6 was not migrated due to partial or ambiguous match."
"Device USB\VID_31DE&PID_1860\5&19f4c0d2&0&6 requires further installation."

There are multiple instances of this since I have been trying to get this to work, but this is what the failure appears to be stemming from. I have done a fair amount of searching for a remedy for this issue, but every resolution I find doesn't seem to work. All my drivers are functioning in device manager, no yellow alert notifications, Ive done the sfc scan, all windows updates, etc. I did see where one of the websites I visited suggested that having 2 operating systems on the same machine can cause migration issues like this, but I'd think parallels would be taking care of the reason that could cause that to occur?? I'm lost. I'll gladly email my event logs to anyone that wants to see it, if that would help.
 
GampaA@Parallels said:
Hello @GarrinC, Please follow the KB article http://kb.parallels.com/9058 to generate a technical report Id. Thanks, Parallels Team.
Click to expand...

I just restarted the instance of parallels and as I was closing the app a pop-up was behind the window asking for permission to record the screen. I am assuming this was needed for the tech report and I missed it. If so here is updated technical report 384213588 it's from a fresh restart right to the issue that I am having so it'll probably easier to navigate. I hope.
 
Hello guys, the newest Parallels Desktop 17.1.1 update has been released recently.
And it resolves a USB devices connectivity issue.
Please check the issue and let us know the results.
 
Hy guys. I'm going through the same inconvenience. Connecting a STM32 - Nucleo F767ZI card that worked with version 16 and does not work with version 17, even after today's update suggested by Mary. I downgrade to version 16 (it is sad to pay for the software update and not be able to use).
The USB serial port appears in Windows, but when opening it does not even receive anything.
 
Maria@Parallels said:
Hello guys, the newest Parallels Desktop 17.1.1 update has been released recently.
And it resolves a USB devices connectivity issue.
Please check the issue and let us know the results.
Click to expand...
Thank you for the information about the update. I performed the update to 17.1.1 just now and it was responsible for the same USB issue that 17.1.0 had where it constantly thinks that my USB device is busy on the host OS and gives me the "Unable to connect USB device to Windows 10" please try again later. https://kb.parallels.com/en/10136 is of NO help. 17.0.1 did not have this problem and is not the issue that I have been fighting.
 
AfonsoM1 said:
Hy guys. I'm going through the same inconvenience. Connecting a STM32 - Nucleo F767ZI card that worked with version 16 and does not work with version 17, even after today's update suggested by Mary. I downgrade to version 16 (it is sad to pay for the software update and not be able to use).
The USB serial port appears in Windows, but when opening it does not even receive anything.
Click to expand...

Sorry to hear that you are in a similar situation as I am in. Do you happen to have the installer file for a stable version of parallels 16 and will it install and run with macOS Monterey? I agree with your position that paying for the upgrade does indeed suck if we can't use it, but I would be willing to (in the interim) roll back to a version where I could get this device to work for just the sheer curiosity to see if it indeed is parallels or if its windows, or the drivers, or macOS causing this issue for me??
 
Hi Garin. I'm not using MacOS Monterey. I am a teacher and I'm waiting for the end of the year to do the update (I live in Brazil and here the holidays are from December to February). I do not want to take the risk of having problems with incompatibility with my work at the end of the semester. Let's wait for the next update...
 
I think I'm facing the same issue. I am playing with Teensy 4.0 development board using Arduino IDE, it is is recognized as a COM port (Windows) or serial device (Mac, Linux). My setup is:
- MacOS Monterey 12.0.1 as host
- Windows10 as virtual machine
- upgrade to the newest Parallels Desktop 17.1.1
Upgrade to Parallels 17.1.1 just partially solved the issue, I am now able to read data at USB serial port. But I am still unable to write any data to the USB serial port, it seems to be stacked or timeout.
 
l3xh2k said:
I think I have a similar problem -- https://forum.parallels.com/threads/esptool-py-not-working-on-linux-guests.355828/
(I'd change the title since my understanding of the problem evolved but there doesn't seem to be an obvious way to do that).
tl;dr there seems to be subtle problems with USB virtualization on the mac (both virtualbox and parallels don't work correctly for me)
Click to expand...


I agree (with the opinion) the virtualization of the USB-serial system is the issue. The reason (as I understand it) for version 17.1.1 being released was to address issues with devices not showing up in windows guest machines. Going back to 17.0.1 fixed this issue (For ME at least) this issue however is still very present in BOTH 17.1.0 AND 17.1.1 - I would really like to try the last stable version of Parallels 16.x.x to see if that corrects my original USB traffic/communication issue.

It does sound like our issues are extremely similar in nature. I don't know if they are directly related to one another or not but I am going to watch your thread and see if anyone chimes in with helpful info for either one of us. Certainly an interesting issue, I just wish I understood it a little better so I could even explain it properly to people that might be able to help. For what it's worth, this device has the FTDI chipset and is supposed to utilize FTDI drivers but the virtualization appears to force the Microsoft drivers for the SERIAL LPT/COM ports and won't even see the device as "plugged in" without the microsoft drivers.... It's beyond me at this point.
 
MarcoM16 said:
I think I'm facing the same issue. I am playing with Teensy 4.0 development board using Arduino IDE, it is is recognized as a COM port (Windows) or serial device (Mac, Linux). My setup is:
- MacOS Monterey 12.0.1 as host
- Windows10 as virtual machine
- upgrade to the newest Parallels Desktop 17.1.1
Upgrade to Parallels 17.1.1 just partially solved the issue, I am now able to read data at USB serial port. But I am still unable to write any data to the USB serial port, it seems to be stacked or timeout.
Click to expand...

Seems we aren't as far and few between as I thought....
Looks like a very similar setup: Monterey, Win10, 17.1.1 - Sounds like a strikingly similar issue with a similar device as well - However, unfortunately 17.1.1 didn't garner the same result in my case. downgrading back to 17.0.1 resumed the ability to recognize the USB by windows but still left me with the original communications issue listed in the original post.
 
From reading similar posts, it seems that it's a hit & miss scenario with the success of 17.1.1 curing SOME of the USB-Serial Com issues for some people. So someone in the dev team is on the right track at least. Here's to hoping that the device I am trying to connect to isn't too obscure to be included in an upcoming patch/update.
 
I'm also having issues with TI's XDS110 debuggers in Parallels 17.1.1 still. Downgrading to 17.0.1 resolves those issues and makes USB reliable again. Parallels really needs to figure this out. It's not okay to ship an update that completely breaks USB, then ship another update that supposedly fixes it but doesn't actually fix it. It's far less reliable than it ever was in 17.1.1.

One of my colleagues keeps saying VMWare Fusion is rock solid for USB (which is one of the things I rely on most). If Parallels can't figure this out soon, I'll have no choice but to switch.
 
You must log in or register to reply here.
Back
Top