Fix: re-enable support for Olimex FT2232C/H adapters #2195

ALTracer commented 2026年02月18日 18:42:55 +01:00 (Migrated from github.com)

Detailed description

• It's not a new feature.
• The existing problem is broken support for Olimex FTDI-based JTAG adapters in BMDA for some time because of the VID:PID filter. I wouldn't be surprised if it goes back to v1.9.0-957-g 9872a98e of #1502.
• This PR solves it by letting additional non-0x0403 VID adapters through that filter and tightening VID:PID values, adding USB product description strings (required for ftdi.c backend)

Tested with 15ba:002b Olimex ARM-USB-OCD-H on Windows 10, I don't have access to the other three adapters. A full 9-pin COM port on interface B is pretty neat to have, even if the board design is >10 years old. SRST pin exists but is not handled, TRST pin exists but ftdi.c backend always uses Go-Idle TMS sequence; it could be set high via initial values of cable desc if some board needs it to be high (to get TAP out of reset). On Windows 10, FTD2XX drivers should be manually associated to it, Zadig WinUSB results in FT API errors (but lets one use OpenOCD), Windows 7-oriented manuals didn't help. I had to add more proper error-handling code to diagnose this, it's not part of this PR.

Basically 15ba:ffff (mask) entry of debugger_devices[] should be let through get_debugger_device_from_vid_pid(), else ftdi.c code is not even reached. Or we can have four specific VID:PID entries, if there are other USB devices from Olimex that BMDA would need to ignore.

For correctness, I've picked the existing 15ba:0003 "olimex" cable desc and renamed it to FS FT2232C "arm-usb-ocd" for what it is, added the supposed description, and encountered another bug/feature that it started matching my HS FT2232H "arm-usb-ocd-h" by the virtue of having a full prefix, so strstr() it not enough. Moving it further down below the HS entry works. For completeness, I've also added 15ba:0004 "arm-usb-tiny", so all four adapter boards should be supported for JTAG-only debug. They're not grouped as strictly the last four cable desc entries, as I wanted to preserve patch context. The JTAG-SWD interposer board with lots of buffers is out of scope of this PR.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

Not opening an issue separately.

## Detailed description * It's not a new feature. * The existing problem is broken support for Olimex FTDI-based JTAG adapters in BMDA for some time because of the VID:PID filter. I wouldn't be surprised if it goes back to v1.9.0-957-g 9872a98e of #1502. * This PR solves it by letting additional non-0x0403 VID adapters through that filter and tightening VID:PID values, adding USB product description strings (required for ftdi.c backend) Tested with 15ba:002b Olimex ARM-USB-OCD-H on Windows 10, I don't have access to the other three adapters. A full 9-pin COM port on interface B is pretty neat to have, even if the board design is >10 years old. SRST pin exists but is not handled, TRST pin exists but ftdi.c backend always uses Go-Idle TMS sequence; it could be set high via initial values of cable desc if some board needs it to be high (to get TAP out of reset). On Windows 10, FTD2XX drivers should be manually associated to it, Zadig WinUSB results in FT API errors (but lets one use OpenOCD), Windows 7-oriented manuals didn't help. I had to add more proper error-handling code to diagnose this, it's not part of this PR. Basically 15ba:ffff (mask) entry of `debugger_devices[]` should be let through `get_debugger_device_from_vid_pid()`, else ftdi.c code is not even reached. Or we can have four specific VID:PID entries, if there are other USB devices from Olimex that BMDA would need to ignore. For correctness, I've picked the existing 15ba:0003 "olimex" cable desc and renamed it to FS FT2232C "arm-usb-ocd" for what it is, added the supposed description, and encountered another bug/feature that it started matching my HS FT2232H "arm-usb-ocd-h" by the virtue of having a full prefix, so strstr() it not enough. Moving it further down below the HS entry works. For completeness, I've also added 15ba:0004 "arm-usb-tiny", so all four adapter boards should be supported for JTAG-only debug. They're not grouped as strictly the last four cable desc entries, as I wanted to preserve patch context. *The JTAG-SWD interposer board with lots of buffers is out of scope of this PR.* ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [x] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues Not opening an issue separately.

dragonmux commented 2026年02月19日 10:23:09 +01:00

For point of note, the VID:PID thing for the Olemex adaptor came in with #1026 which was a cherry-pick of a patch from Uwe which we had to just trust had the right VID:PID present. Sid's PR is not to blame for that.

For point of note, the VID:PID thing for the Olemex adaptor came in with #1026 which was a cherry-pick of a patch from Uwe which we had to just trust had the right VID:PID present. Sid's PR is not to blame for that.