Known issue with USB-to-CAN V2 and recent Windows 10 updates?

Ixxat Support USB To CAN
#1

Hi,

We have a fairly simple software tool which has been running on a laptop with a USB-to-CAN V2 without problems for over a year. Suddenly in May 2021, it stopped working.

We’ve reinstalled Windows 10 from scratch, installed the VCI 4 driver, and retried with the same results. In our software and in CANanalyser, it appears as though both channels are disconnected Both channels behave identically (no activity) if I try to send a message on CANanalyser.

I’m able to use the same USB-to-CAN V2 several other laptops running Windows 10 and if I send a message on channel 0 in CANanalyser I see some activity.

The other laptops I tested on are running Windows 10 Enterprise 18363. The laptop where it’s not working is running Windows 10 Professional build 19042 which lines up with the issue starting in May…

I’m planning to try a few of the troubleshooting tips suggested here in the next week. I’ll try updating the firmware on the USB-to-CAN V2 and I’ll try running it using a powered USB hub.

Wondering if anyone here can help me understand whether there is a known issue introduced by the recent Windows release which may have caused the device to stop working suddenly only on that laptop.

#2

Hi @calb,
I haven’t heard of any issues with new versions of windows 10.

Does the device show up correctly in device manager? Try uninstalling the device from device manager then scanning for device changes to make sure it is picking up the new driver.

Deryck

#4

Yeah, it shows up in device manager, and it shows as registered to the Ixxat VCI 4 driver (not a generic usb device). I did initially try your suggestion un/reinstalling in device manager. Like I said, we also had the entire laptop wiped and Windows reinstalled, then the VCI driver. Still no luck.

It seems that communication with the USB-to-CAN V2 works correctly. It shows as connected in our custom software and in canAnalyser. But communication with the CAN device doesn’t work, only on this particular laptop, and only as of last month. Before that it worked fine.

#5

I would think the issue would be with the CAN phy besides the fact that its working on other PC’s. Is there an update for the USB drivers or chipset on that pc?

Have you updated the firmware on the USB to CAN yet?

I am going to open a case in out ticketing system to see if the Ixxat engineers have any input.

#6

My colleagues had the following questions regarding the setup.

  1. The laptop where it’s not working is running Windows 10 Professional build 19042
    which lines up with the issue starting in May…

1.1. Could you please update to Windows 10 20H2 and
let me know if the problem still occurs?

1.2. Could you please let me the exactly Laptop type?

  1. We’ve reinstalled Windows 10 from scratch, installed the VCI 4 driver

    Could you please let me know the exactly VCI V4 version number?
    VCI V4.0.939.0? (See the “control panel | programs and features | IXXAT”)

  2. Could you please let me know the product version of the used USB-to-CAN V2.
    (You can find the product version on the label of the USB-to-CAN V2)
    (or please send me a photo of the label on the USB-to-CAN V2)

  3. Which firmware is running on the USB-to-CAN V2?
    (You can find the version of the running firmware in the device manager
    “USB-to-CAN V2 properties | hardware info”)

    Please update the firmware up to V1.7.0 if any older firmware are running
    and let me know if the problem still occurs.

  4. I’ll try updating the firmware on the USB-to-CAN V2 and
    I’ll try running it using a powered USB hub.

    Could you please let me the result?

  5. Does the problem occurs with another USB-to-CAN V2 on this laptop?

  6. Could you please let me know the use case of your USB-to-CAN V2?

#7

Hello @calb,

Any more details on this before I mark this as solved?

#8

Hey deryck,

I’ll be doing more troubleshooting on this issue later this week, and I can provide an update then.

Thanks.

#9

How did trouble shooting go this week?

#10

Hey deryck,
Sorry to say we didn’t get to make any progress this week. We hard ordered a powered USB hub for one of the troubleshooting ideas in case the issue was related to USB power, but we recieved a non-powered hub. So we’re still waiting on the replacement, likely early next week. The laptop is offsite and requires travel, so trying to consolidate next troubleshooting steps in a single trip when the hub arrives.

#12

Hey Deryck,

1.1) I wasn’t able to change the Windows version. Currently on 10.0.19042

1.2) Laptop is a Dell Inspiron 5584

  1. VCI V4 driver version is 4.0.939.0 according the “Apps & Features”. In

  2. The USB-to-CAN V2 device is encased in an additional enclosure and I didn’t have the tools to open the enclosure. The VCI4floadGUI.exe app displays the Hardware version as V 00.01.05.00 if that helps. Serial number is HW538586.

  3. Previously the USB-to-CAN V2 was running Vci4_bal: V00.01.06.03 but today I tried updating the firmware to V00.01.07.00 and it was unfortunately still unsuccessful.

  4. Neither the firmware update nor the externally powered USB hub helped the situation.

  5. I tested using a second USB-to-CAN V2. It’s an older one, firmware 00.01.05.04, Serial HW429257. Same issue. Both USB-to-CAN V2 devices are tested as working with other laptops.

  6. It’s being used with custom software to read data from a custom hardware device. We use the same piece of software at multiple stations in our manufacturing office for verification without any problems. The particular laptop in question is at a vendor’s facility where they perform the same verification. It was working on the vendor’s laptop for over a year until May 2021 when it suddenly stopped working without any known change on their end (which is the reason I worry it may be related to a recent windows update).

On my laptop (or any other computer where the USB-to-CAN V2 is working fine) with the USB-to-CAN V2 connected to our CAN device on channel 1, then click “Transmit Single Message”, I see a single row appear in the output window with State = “S”. If I try the same thing without anything connected to channel 1, I see a continuous stream of messages like:
“No”,“Time (abs)”,“State”,“ID (hex)”,“DLC”,“Data (hex)”,“ASCII”
“1,682”,“00:02:01.094”," “,“Error”,“1”,“00h : TX | bit error”,”"

If I try the same thing on the vendor’s laptop, with the same USB-to-CAN V2 devices, I get the “TX | bit error” messages every time, whether a CAN device is connected to channel 1 or not. It seems that the USB-to-CAN V2 is detected and assigned the proper drive, and communication with the USB-to-CAN V2 works as expected, but the USB-to-CAN V2 is failing to TX/RX on its CAN ports.

Any other ideas for me to try?

Thanks,
Chris

#14

  1. The VCI4floadGUI.exe app displays the Hardware version as V 00.01.05.00
    if that helps. Serial number is HW538586.
    Previously the USB-to-CAN V2 was running Vci4_bal: V00.01.06.03
    but today I tried updating the firmware to V00.01.07.00 and
    it was unfortunately still unsuccessful.
    Neither the firmware update nor the externally powered USB hub helped the situation.

    Please update the firmware of the USB-to-CAN V2 HW538586 up to V1.7.0 using another PC
    (not on the Dell Inspiron 5584) and then please let me know if the problem does not occur using the USB-to-CAN V2 FW V1.7.0 on the Dell Inspiron 5584 anymore.

  2. I tested using a second USB-to-CAN V2.
    It’s an older one, firmware 00.01.05.04, Serial HW429257.
    Same issue.
    Both USB-to-CAN V2 devices are tested as working with other laptops.

See above

  1. If I try the same thing on the vendor’s laptop,
    with the same USB-to-CAN V2 devices,
    I get the “TX | bit error” messages every time,
    whether a CAN device is connected to channel 1 or not.
    It seems that the USB-to-CAN V2 is detected and assigned the proper drive,
    and communication with the USB-to-CAN V2 works as expected,
    but the USB-to-CAN V2 is failing to TX/RX on its CAN ports.

3.1. Transmitting with out connected CAN nodes, but
with a correct termination of the CAN bus
you should get the “TX | bit error (acknowledge slot)”
because of the missing acknowledgement.

3.2. Could you please measure the resistance between CAN_H and CAN_L?
Make sure there is termination (120Ω) on both ends of the bus It should be 60 Ohm (2x120 Ohm in parallel).

3.3. Is the second CAN node initialized and started with the same CAN baudrate?

3.4. Can you measure the CAN Signal Level using an oscilloscope?

3.5. If the CAN-Transceiver got broken,
then the CAN communication would not successfully run
on another PC also.
Could you please confirm
that the both USB-to-CAN V2 (HW538586 & HW429257)
can not successfully transmit CAN messages
using Dell Inspiron 5584 but
can not successfully transmit CAN messages
using a PC of another type.

#15

Hey deryck,

Just to be clear, we did try two different USB-to-CAN V2 devices and both of them fail on the Dell 5584 but succeed on every other PC we tried. We tried several others. I don’t think it’s a hardware failure.

However, we ended up replacing the laptop with a small mini pc which works successfully, so I won’t be able to perform any more troubleshooting on that laptop for the time being. If the problem recurs on the mini pc, I’ll reach out again.

#16

Also, wrt 3.1, what I was trying to point out was that on the Dell 5584, the behavior when attempting to transmit with a correct termination behaves the same as trying to transmit without correct termination on other PCs. That is, on the Dell 5584 when there is a device connected to the channel 1 bus, I was still getting the “TX | bit error” message, as though there was nothing connected.

#17

Hi @calb ,

Thanks for the update. Let us know if you have other issue.

I had forgotten the firmware files, here is a copy incase they are needed. USB-to-CAN-V2-Firmware.zip (538.8 KB)

#18

I have an update here, just in case anyone comes across this post having a similar issue.

This turned out to be a combination of some sort of difference in the way the Ixxat VCI driver works before/after the Windows 20H2 update (confirmed that my application works as usual before the update and fails after the update) and a code issue on my end that was masking the real issue.

As for the difference between the way the VCI API worked before and after the 20H2 update:
My code for communicating over the CAN channel was generally doing the following:

  1. Transmit using canChannelSendMesage()
  2. Once complete, loop checking canChannelGetStatus() until the sLinestatus.dwStatus != CAN_STATUS_TXPEND, meaning transmit is not still pending
  3. Receive using canChannelReadMessage(), looping until a timeout is reached until the result is VCI_OK and the CANMSG.uMsgInfo.Bytes.bType = CAN_MSGTYPE_DATA

Before the 20H2 update, checking canChannelReadMessage() very soon after canChannelSendMessage() was never returning VCI_E_RXQUEUE_EMPTY. However, after the update, the result of the first check to canChannelReadMessage() is always returning VCI_E_RXQUEUE_EMPTY on the first call.

In my code, I found that I had a bug where I was handling most error conditions from canChannelReadMessage(), but I was eating the VCI_E_RXQUEUE_EMPTY message (considering it the same as VCI_OK). When I add even a 10ms sleep before checking canChannelReadMessage(), it never returns VCI_E_RX_QUEUE_EMPTY anymore.

Since this is probably a race condition and the 10ms might not always be adequate, the more appropriate fix was in case the result is VCI_E_RX_QUEUE_EMPTY, sleep for 50ms, and keep trying until a timeout is reached. This way even if I hit VCI_E_RX_QUEUE_EMPTY on the first check, I keep checking until the result is VCI_OK or my timeout is reached. This fixed my application.

So it was a race condition introduced by the Windows update, hidden by a bug in my code. Perhaps some part of the 20H2 Windows feature update improved performance of the VCI driver just enough that I’m checking the RX queue too quickly, where before the 20H2 update there was a long enough delay. I don’t know the details but this is what I found.

#19

Also, as part of troubleshooting this fix I re-built my application which was originally built against the SDK for v3 of the VCI driver. During that process, I found that the new file stdtype.h in the latest set of headers included with the SDK in v4 explicitly excludes compiling using GCC, which is the compiler I used originally without any issues. Because of this, I had to hack my own version of stdtype.h including support for GCC.

Attaching my updated stdtype.h with GCC support. Maybe your development team can include it in a future release. These are the changes I made:

  1. Define types __INT8, __UINT8, __INT16, etc, on based on the GCC types int8_t, uint8_t, int16_t… etc.
  2. Set the endianness based on standard GCC macros for byte order.
  3. Comment out the min/max macros. It’s pretty nasty practice to define macros of lower case min()/max() in a C header… Sooooo many libraries define their own functions called min/max and having macros with the same names screws up compliation in all those cases. Even standard libraries like the STL vector library define min/max internally. If the VCI driver code actually uses these macros anywhere, they should be renamed to MIN/MAX or _min/_max or something.

Thanks,
Chris

#20

Sorry to reply thrice in a row, but I forgot to attach my updated stdtype.h as I mentioned and I can’t edit previous posts.
stdtype.h (35.3 KB)

#21

Hi Calb,

Thanks for the update and feedback! I have forwarded this feedback over to the developers as well.