[OpenOCD-devel] To Zadig or not to Zadig?

[Liviu Ionescu]

maybe this is a classical, but...

---

I prepared a new release of GNU MCU OpenOCD (formerly GNU ARM OpenOCD), which is based on the latest master; to it I merged the latest RISC-V OpenOCD master, which adds support for the new RISC-V devices (thus the reason for rebranding).

my elaborated build procedure generates binaries for windows 64, windows 32, linux 64, linux 32, macos; the binaries are (hopefully) self contained, they do not need special libraries present in the system.

I have a new RISC-V board, the SiFive Freedom E300 HiFive1, with a modern FTDI chip on-board, used to connect to the JTAG pins.

I have an OpenOCD configuration file for this board, written by the board manufacturer (SiFive).


if I connect the board to my macOS 10.12, with the default FTDI drivers installed in the system, I automatically get two 'Dual RS232-HS' interfaces:

Product ID: 0x6010
Vendor ID: 0x0403 (Future Technology Devices International Limited)
Version: 7.00
Speed: Up to 12 Mb/sec
Manufacturer: FTDI
Location ID: 0xfd122300 / 4
Current Available (mA): 500
Current Required (mA): 500
Extra Operating Current (mA): 0


but if I try to connect OpenOCD to it, it fails:

$ bin/openocd -f board/sifive-freedom-e300-hifive1.cfg
GNU MCU Eclipse 64-bits Open On-Chip Debugger 0.10.0+dev-00474-g275b04dd (2017-06-07-15:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: libusb_claim_interface() failed with LIBUSB_ERROR_ACCESS
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Dual RS232-HS', serial '*' at bus location '*'



if I do the same on a Windows 10 machine, with the latest FTDI drivers installed directly from FTDI, I get a more or less similar error message:

C:> bin\openocd.exe -f board\sifive-freedom-e300-hifive1.cfg
GNU MCU Eclipse 32-bits Open On-Chip Debugger 0.10.0+dev-00473-g8770f7f-dirty (2017-06-07-11:53)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: libusb_open() failed with LIBUSB_ERROR_NOT_FOUND
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Dual RS232-HS', serial '*' at bus location '*'


on a separate Windows 7 virtual machine, after getting a similar message, I installed the famous 'Zadig', which did some magic and then allowed my OpenCOD to connect to the board.


it looks like I am missing something with the usb configurations. I checked the OpenOCD manual, but could not find an answer.

first question: what is the recommended configuration for windows to connect to FTDI boards? is Zadig really mandatory? I read countless horror stories recommending **not** using Zadig, but without Zadig I could not find a way to configure OpenOCD to connect to the board.

second question: for macOS the situation is even more strange; using other FTDI devices was flawless, but OpenOCD refuses to connect to this board.


any suggestions?

thank you,

Liviu

[Anders Montonen]

<snip>

A kernel mode driver has grabbed the device, either Apple’s AppleUSBFTDI or FTDI’s own. To find out which, try eg. “kextstat | grep -i ftdi”, or IORegistryExplorer.

The driver can be temporarily disabled, as described here: <https://www.decisivetactics.com/support/view?article=disable-appleusbftdi-driver <https://www.decisivetactics.com/support/view?article=disable-appleusbftdi-driver>>. You can also install a codeless kext to prevent any other driver from matching the device, see <https://developer.apple.com/library/content/technotes/tn2315/_index.html <https://developer.apple.com/library/content/technotes/tn2315/_index.html>>

Regards,
Anders

[Paul Fertser]

Hello Anders,

Post by Liviu Ionescu
if I connect the board to my macOS 10.12, with the default FTDI drivers
<snip>
A kernel mode driver has grabbed the device, either Apple’s AppleUSBFTDI or
FTDI’s own. To find out which, try eg. “kextstat | grep -i ftdi”, or
IORegistryExplorer.
<[2]https://www.decisivetactics.com/support/view?article=disable-appleusbftdi-driver>.
You can also install a codeless kext to prevent any other driver from matching
the device, see
<[3]https://developer.apple.com/library/content/technotes/tn2315/_index.html>

We already have some related information in README.OSX. Can you please
review it and clarify if anything is missing there or the wording is
suboptimal?

TIA

[Paul Fertser]

this is suboptimal as approach, not as wording.

It has a link about registering a driverless kext and with that I
guess you can make the driver ignore just one specific device, not all
FTDI converters.

there are many other FTDI applications out there (I have and use
some) which rely on this standard behaviour. what do you think will
happen to all these devices if I unload the FTDI kext?

They won't be working during the debug session, granted, but will
start working after kext loading or OS restart.

and, if I remember right, exactly the same thing happens on Windows,
if I install the standard FTDI drivers, when I connect the same
HiFive1 board I also get two new serial ports.

On windows you can install WinUSB specifically for a device, so it
won't affect anything else. Another possible approach is to use UsbDk
(see my other mail).

so, the natural question would be: is it possible to access the
programming pins via the standard serial port? (in principle, not
with existing OpenOCD support). if so, with an appropriate
implementation, using OpenOCD with FTDI probes on Windows and macOS
wouldn't be a no-go, as it is now.

Serial port abstraction provided by an OS is certainly not adequate to
be able to talk MPSSE to the chip I think, so that's not an option.

Plenty of people are using FTDI debug adapters on windows and OS X
already, as far as I know.

[Liviu Ionescu]

Post by Paul Fertser

there are many other FTDI applications out there (I have and use
some) which rely on this standard behaviour. what do you think will
happen to all these devices if I unload the FTDI kext?

They won't be working during the debug session, granted, but will
start working after kext loading or OS restart.

sorry, but this is not an acceptable solution :-(

Post by Paul Fertser
Serial port abstraction provided by an OS is certainly not adequate to
be able to talk MPSSE to the chip I think, so that's not an option.

ah, right. I thought the programming pins are connected to the handshake/modem signals, which can be toggled, but if this is not the case, then it is not an option.

Post by Paul Fertser
Plenty of people are using FTDI debug adapters on windows and OS X
already, as far as I know.

poor them...


regards,

Liviu

[Anders Montonen]

there are many other FTDI applications out there (I have and use some) which rely on this standard behaviour. what do you think will happen to all these devices if I unload the FTDI kext?

If your other devices aren’t using specifically 2232H chips as serial ports, you can use a kext that matches only that VID/PID pair.

so, the natural question would be: is it possible to access the programming pins via the standard serial port? (in principle, not with existing OpenOCD support).

Not that I’m aware of, but you could try asking on Apple’s USB developer mailing list or developer forums.

IMO the right thing would be for device vendors to use a custom VID/PID when the FTDI chips are not used as plain serial ports, and supply the necessary inf files/kexts/udev rules to map the wanted functionality.

Regards,
Anders

[Liviu Ionescu]

... IMO the right thing would be for device vendors to use a custom VID/PID when the FTDI chips are not used as plain serial ports, and supply the necessary inf files/kexts/udev rules to map the wanted functionality.

that's exactly my conclusion too :-(

the fact is that standard ftdi drivers, when encounter standard ftdi ids, associate them with virtual serials. at least on macOS and windows.

on macOS the only 'legal' solution is to use devices that have vendor IDs, so the association with the default virtual serial driver is no longer done.

to be noted that some ftdi devices have an eeprom and with an windows program provided by ftdi, some settings can be changed.

for windows, instead of using Zadig, I discovered a less invazive method: libusbK:

https://sourceforge.net/projects/libusbk/

it generates a WinUSB driver for a given vid/pid. this driver has a more or less usual setup, that can be not only installed, but also uninstalled. :-)


unfortunately, for macOS there is no such trick...


regards,

Liviu

[Liviu Ionescu]

Post by Anders Montonen

there are many other FTDI applications out there (I have and use some) which rely on this standard behaviour. what do you think will happen to all these devices if I unload the FTDI kext?

If your other devices aren’t using specifically 2232H chips as serial ports, you can use a kext that matches only that VID/PID pair.

btw, my other devices are exactly usart adapters. I chose this FTDI based model because they do not require any extra drivers and work quite fine on macOS.


regards,

Liviu

[Peter Stuge]

This post might be inappropriate. Click to display it.

[Liviu Ionescu]

...

thank you Peter for your detailed response.

I confess that I do not understand many of the details, but I have a bad feeling about this... :-(


regards,

Liviu

[Paul Fertser]

Hello Peter,

Thank you for clarifying the topic. I have some minor note to add.

Post by Peter Stuge
Of course, if your vendor software requires a different driver and
Windows is set to use WinUSB.sys, then you have a horror story on
your hands - because the device will then *only* work with OpenOCD.

There is now an alternative called UsbDk [1] which is similar to
filter driver of libusb-win32 but is supposed to be more reliable.

It should allow using whatever vendor driver and automatically
"borrow" the device for libusb applications when needed.

Unfortunately, the UsbDk backend in libusb can't coexist with WinUSB
backend, it's selected during the configuration stage.

One can try the UsbDk-enabled libusb by means of using libusb-usbdk
package in MSYS2.

HTH

[1] https://github.com/daynix/UsbDk