Reprogram Axe027 to 6001 PID

[bhanlon56]

I normally use the "double install" method for the axe027 cable. I delete the windows drivers (from Device Manager) and then manually find the driver from a folder on my pc. After a successful driver install it comes up with AXE027 PICAXE USB COMx under Ports in Windows Device Manager. It works but can be difficult to describe to people not familiar with computers.
I thought I'd try reprogramming the axe027 cable from a pid of bd90 to 6001. This has the major advantage that the standard windows drivers will just work. At least that's what I expected.
I've reprogrammed the axe027 cable using both the ftdi utility and the proaxe027 utility. It appears to program successfully with either utility. I re-inserted the cable, deleted the drivers, removed the cable and re-inserted. Windows I assumed then installs the standard ftdi driver. It appears as a plain COMx port in Device Manager. However, on programming a 08M2 chip I get a "Hardware not found" error.
I've also tried repeating this process using the drivers available from the ftdi website.
Strangely, reprogramming the axe027 back to a pid of bd90, removing the drivers and doing a "double install" of the picaxe drivers also results in "hardware not found" message. I did check the Device Manager. It reports the port name as AXE027 PICAXE USB COMx.
So, how can I use a pid of 6001. Or, failing that, how do I roll back to the original driver successfully?

 

[PhilHornby]

I normally use the "double install" method for the axe027 cable. I delete the windows drivers (from Device Manager) and then manually find the driver from a folder on my pc. After a successful driver install it comes up with AXE027 PICAXE USB COMx under Ports in Windows Device Manager.

Climbing onto my hobby horse ...

Unfortunately, using the 'supplied drivers', means using drivers (2.08.14) that are not certified for Windows 8, let alone Windows 11. At least three potential B.S.O.D. scenarios are present in those drivers (according to the Release Notes for later versions).

I thought I'd try reprogramming the axe027 cable from a pid of bd90 to 6001. This has the major advantage that the standard windows drivers will just work. At least that's what I expected.

You would need to download the latest drivers from the FTDI site for this scenario to work - the FT232R in the AXE027 is not supported by USBSER.SYS (aka the 'standard windows drivers').

You're probably familiar with the "Hardware IDs" section in Device Manager, but if you look at a device that is supported by the USBSER.SYS, you'll see that it has a "Compatible IDs" section, which is not present for the FT232R/AXE027.



(The section "Matching Device id" is always useful to check as well - it shows which ID was used to actually select the driver. Another entry "Generic Driver Installed = <true> also sometimes appears)

So, how can I use a pid of 6001. Or, failing that, how do I roll back to the original driver successfully?

You first need to remove both parts of any FTDI drivers (one under "Ports (COM & LPT)" and the other, appearing as a "USB Serial Converter" under "Universal Serial Bus Controllers"). Enable View -> "Show Hidden Devices", to ensure you find them all.

Then you can either set the ID back to "BD90" and install the Rev Ed. drivers - or set the ID to 6001 (or any of the others in the INF file) and use the latest manufacturer supplied drivers. [I then searched the Registry and manually renamed them from "COMx:" to "PICAXE AXE027 USB Serial Port (COMx)" - definitely not recommended ]

(At some point, I managed to set the Hardware ID back to 0xBD90, without Windows trying to overwrite them with the older drivers).

EDIT: I've just remembered a gotcha I encountered - FT_PROG requires that the device has a valid driver installed. ISTR having to use a second PC to get around this!

Whichever drivers you use, there are still two 'devices' to be installed, before they work.

I do some to recall having some grief at various points in proceeding and having to resort to clearing up the driver store manually, to get out of a mess of my own making!

Also note: with the latest drivers installed, I often have to remove-and-replug the AXE027, to get it to recognise the Picaxe, which is not something which happened in the past. I'm suspicious that the latest drivers are maybe not that good a match for the pretty ancient hardware. But there again, I've recently bought a new PC and a zillion other configuration differences could be responsible for this effect.

 

[bhanlon56]

Yesh!
Thanks for the information. I turned on "show hidden devices" and removed all instances of any usb drivers. Did a double install of picaxe drivers. Reprogrammed the axe027 back to bd90. Device manager reports a hardware id of:
FTDIBUS\COMPORT&VID_0403&PID_BD90
So I think the driver is installed correctly. But I still can't detect the piaxe chip

 

[Flenser]

The "Hardware not found" error can be caused by connection problems with the download circuit on the PICAXE chip. It does not indicate that there is a problem with the USB driver installation.

Perform a serial port loopback test as described here Fault finding FAQ.
If this test passes then there is no problem with your USB driver installation, it is somewhere else.

 

[Goeytex]

After Programming with FT_PROG, the adapter must be "reset" for changes to take effect. So unplug and plug it back in. This is particularly true when changing the I/O's from normal to inverted or vice versa. If perhaps the EEPROM was erased, make sure the I/O's are configured to be inverted before flashing the EEPROM. Again reset the adapter.

If the loopback test passes then the most likely cause of "hardware not found" is a wiring error. If wiring is OK, then perhaps try a hard reset.

 

[hippy]

But I still can't detect the piaxe chip

It probably has nothing to do with USB PID nor Windows drivers - It is probably just a PICAXE requiring a Hard Reset procedure, doing something which prevents it being reprogrammed no matter what programming cable were being used.

To initiate a Hard Reset - Power off the PICAXE board, wait a few seconds. Initiate a download, then, a second or so later, turn on the power. It can take a few tries to get used to the timing of that, so don't give up if that doesn't work immediately.

As to Windows drivers; providing it appears as a COMx port when plugged in, you can program the PICAXE chip - then that is usually good enough to say that however things are set they are correct.

 

[bhanlon56]

@hippy. Hard Reset fixed it.
@Goeytex. I did that. Even rebooted the pc.
@Flenser. Didn't know about the loop back test for the axe027 cable. Thanks for the info.
@PhilHornby. After a hard reset, I followed your instructions to delete all driver files. Inserted the axe027 and let win10 do its thing. I was going to use the drivers from the ftdi website but the win10 ones appear to work. Which I wanted in the first place.
Thanks to all. Appreciate the help.

 

[erco]

All this finnicky ftdi fiddlin' makes a great case for a CP2102 or CH340 adapter. Totally plug and play, no ftdi bricking (!), cheap and widely available.

 

[PhilHornby]

The CH340 is no paragon of virtue in this regard

In addition to the Hardware Id provided for its own (somewhat elusive driver), its "Compatible IDs" section, says it can use the in-built Windows AUDIO USB class driver. It can't - so you still have to play 'hunt-the-driver'. Of course, this error might be peculiar to the CH340-based adapter I have acquired...

EDIT: I tried forcing it to use the in-built Windows Serial class driver - it installs, but it doesn't actually work.

It turns out to be better to let Windows Update find it and download something appropriate - all the drivers I found on the web were ancient.

 

[hippy]

ll this finnicky ftdi fiddlin' makes a great case for a CP2102 or CH340 adapter. Totally plug and play

Not totally plug and play. If one has an RS232 adapter one will probably need a 9-Way D to jack plug cable and, if it's a breakout module, one will likely need to build additional hardware to invert signal polarity.

In terms of Windows drivers I have found the AXE027 drivers to be no more problematic than any others, mostly problem free.

And, the problems here were not actually anything to do with the AXE027, Windows drivers, or even reconfiguration of PID.

The OP would have encountered the same problems they did no matter what cable they were using, even non-USB RS232.

 

[Goeytex]

@erco

FTDI bricking is a thing of the past. This was an isolated case of unnecessary "FTDI fiddling". Genuine FTDI devices are generally not finicky at all and I prefer them in most cases.

However for the budget minded either CP2102, CP2104, or CH340 ( as well as others) can be used for Picaxe programming with the addition of external inverters. These all work fine. I have had no driver issues with the above using Windows 10.

In regards to cost savings ... One can have a geniuine FTDI device for less than $8.00 US. This is the UMFT234XF. This is a small footprint module manufactured by FTDI . It can be directly soldered onto another PCB or header pins can be added and it can be used on a breadboard. It can be programmed via FT_PROG to invert the data lines as required for Picaxe Programming. Along with RX/TX, It also brings out RTS, CTS, +VBUS, and 3.3V (50ma). I have found find it quite useful when I want to embed the programmer/adapter into a particular device. Available from Mouser and others.

 

[erco]

Most of the USB adapters I have built are CP2102-based, using Goeytex's inverter mod. I often take these into classrooms to teach programming Picaxes, when we plug them in to student's laptops they just work. Win10 build 1803 had a hiccup but that was fixed. I also bring Silabs' drivers on a flash drive just in case but we rarely have to use it.

My modded CH340 adapters also work extremely reliably using Goeytex's mod. I sometimes make let older students solder their own modded adapters, a great first DIY project IMO.

 

[PhilHornby]

Climbing onto my hobby horse ...

Unfortunately, using the 'supplied drivers', means using drivers (2.08.14) that are not certified for Windows 8, let alone Windows 11. At least three potential B.S.O.D. scenarios are present in those drivers (according to the Release Notes for later versions).

What I forgot to mention ... is that the old drivers also prevent the "Memory Integrity" feature from being enabled.

See: Settings >>> Update & Security >>>Windows Security >>> Device Security >>> Core Isolation

You'll find you can't enable the feature with the old drivers loaded.



If it is a Windows installation of advancing years, no doubt there'll be other culprits as well. (The screen print above, is from a 10 year-old PC, with no fewer than 20 suspect drivers installed! It generally only runs Hyper-V virtual machines, so I'm not too concerned....)

 

[hippy]

See: Settings >>> Update & Security >>>Windows Security >>> Device Security >>> Core Isolation

If it is a Windows installation of advancing years, no doubt there'll be other culprits as well. (The screen print above, is from a 10 year-old PC, with no fewer than 20 suspect drivers installed! It generally only runs Hyper-V virtual machines, so I'm not too concerned....)[/COLOR]

I had never ventured that deep. I discovered my "Memory Integrity" feature was turned off when I did. Trying to turn it on got me the same issues; 'ftdibus.sys' and an Intel 'idgkmd64.sys'. Given the Intel driver relates to 'oem0.inf' and 'oem1.inf' I suspect it's something needed for the PC.

As you noted, numerous drivers prevent "Memory Integrity" being turned on, so perhaps most people couldn't, and it is likely not something to worry over, just another optional level of protection. It probably has a performance hit as well if one does.

At least three potential B.S.O.D. scenarios are present in those drivers (according to the Release Notes for later versions).

In all my years of using our FTDI drivers I have never experienced a BSOD caused by that, don't recall any reports of such.

I wouldn't dismiss it as not being a real bug but expect it's such an outlier that one would be real unlucky if they did trigger it. It's probably a 'more chance of winning the lottery or being hit by a meteorite' scenario.

 

[PhilHornby]

I had never ventured that deep. I discovered my "Memory Integrity" feature was turned off when I did.

Apparently it was always off, by default in Windows 10. In Windows 11, it's on by default - which may be what got my attention.

Trying to turn it on got me the same issues; 'ftdibus.sys' and an Intel 'idgkmd64.sys'.

There's a possibility of a fixed Intel driver - either via Windows Update, or Intel's own updater. However, it may be like the PC I was looking at, where "Peak Video Driver" was apparently reached in 2015

In all my years of using our FTDI drivers I have never experienced a BSOD caused by that, don't recall any reports of such.

I'm sure if you asked FTDI Chip nicely, they'd tell you exactly how to reproduce them. Backup your system first

 

[Goeytex]

I have been running WIN10/64 on an older Core I5 for years with both ftdibus.sys and idgkmd64.sys preventing Memory Integrity from being enabled. No issues from these that I am aware of. Have never had a BSOD on this Dell Optiplex 7010 ... Ever. This PC with Win10/64 has been the most reliable system I have ever had.

The latest HD Graphics Drivers from Dell, Intel, or Widows Update do not resolve the idgkmd64.sys issue with Memory Integrity and neither does the latest FTDI driver resolve the ftdibus.sys issue.

 

[PhilHornby]

I have been running WIN10/64 on an older Core I5 for years with both ftdibus.sys and idgkmd64.sys preventing Memory Integrity from being enabled.

FTDI must have imagined the bugs they fixed ...

neither does the latest FTDI driver resolve the ftdibus.sys issue.

Can't comment on the Intel issues, but the version of the FTDI driver that I have installed, certainly does resolve the Memory Integrity feature issue:-



Maybe I'm not running the latest driver and they've broken it again.

 

[bhanlon56]

@Goeytex
This was an isolated case of unnecessary "FTDI fiddling"
I've taught introductory electronics and picaxe programming for a few years. I'm no expert. At the start of a course you just want that LED to flash. Students get a sense of achievement and you're on your way.
In a class environment the axe027 installation is often (almost always) a hurdle. Most people expect that when you plug something into a USB port it just works. If changing the pid to 6001 prompts this behavior, I'm all for it. Would have done it years ago.
@hippy
Why is the pid bd40 and not 6001?
When I started teaching with picaxe, this platform had a distinct price advantage over other platforms. It also produced a smaller footprint on a pcb. These days I can buy competing development boards from Asian suppliers at the same price as picaxe and almost as small. Things like the rigmarole of the axe027 installation in a classroom are significant considerations as to what platform a teacher selects.

 

[PhilHornby]

Why is the pid BD90 and not 6001?

Somewhere in FTDI's documentation, this is listed as a recommended practice! The pros & cons are indeed debatable, but one con, is the need to periodically obtain the latest driver package, include the modified .INF that supports 'BD90' and re-sign it. This has not been happening...

 

[erco]

Things like the rigmarole of the axe027 installation in a classroom are significant considerations as to what platform a teacher selects.

Agreed. Even using the easier-to-install CP2102 and CH340 adapters, I have found that it's very time consuming to hope that everyone's computer can sort out the drivers the first time, it's wasted most of a class period before. It's easier for me to provide laptops for everyone with USB drivers and PE5 (yes PE5!) loaded and ready to go. I have amassed quite a collection of 30+ cheap used Toshiba laptops, purchased off Ebay for $20-$50 each. Most worked fine, some needed repair (BIOS lock is common problem, easy to repair). I actually enjoy fixing them, it's a sickness. Then again I enjoy soldering custom PCBs for each new project.

BTW I learn a lot about PC component-level repair from Sorin's Youtube channel. AFAIK he's a Russian tech working in a UK repair shop, possibly London.

 

[papaof2]

Sometimes those "ancient" laptops are worth a great deal ;-)
I had a Micron II (Win 98) dedicated to PICAXE experimentation. The laptop isn't worth anything on the market but it does all that's needed to run PE5.

 

[Goeytex]

FTDI must have imagined the bugs they fixed ...

Can't comment on the Intel issues, but the version of the FTDI driver that I have installed, certainly does resolve the Memory Integrity feature issue:-

Maybe I'm not running the latest driver and they've broken it again.

My system reported the same version as yours (ftdibus.sys 2.12.36.4), yet memory integrity reported a driver incompatibility with ftdibus.sys. So I searched my system and saw multiple FTDI driver packages on the system, mostly from MPLABX/SEEGER as well as REV-Ed. (My FTDI devices are all 403/6001). So I whacked them all. As well as the drivers/files in Windows/System32/DriverStore.... Had to modify "permissions" to get that done.

Then I deleted the existing ftdibus.sys from Windows/System32/Drivers. Then rebooted. Plugged in a geniune FTDI adapter and as expected it failed to create a com port. Then I restored the deleted ftdibus.sys and tried again. Com ports (FTDI) now good in Device Manager and now there is no more conflict with Memory Integrity related to ftdibus.sys. But alas there seems to be no fix for the Intel HD Grapics driver.

 

[PhilHornby]

So I whacked them all. As well as the drivers/files in Windows/System32/DriverStore.... Had to modify "permissions" to get that done.

Might be time for a "SFC /SCANNOW", just to check the DriverStore's integrity

I think in general, PnPUtil is the weapon of choice - just because it's more likely to find all the offending components, of any particular
driver: pnputil /delete-driver <example.inf> /uninstall .

(Dism is useful for listing the installed drivers: dism /online /get-drivers /format=table)

Com ports (FTDI) now good in Device Manager and now there is no more conflict with Memory Integrity related to ftdibus.sys. But alas there seems to be no fix for the Intel HD Grapics driver.

Well that's a step forward. Shame about the video driver, but par for the course

 

[bhanlon56]

@erco
My solution for a high school group was puppy linux. The operating system ran from a usb drive. I used axepad. Still like it. Loads quickly on old laptops and is easy to use. Only thing missing was a simulator. Started using Blockly in anticipation of having a mac user. I think it has promise. Its especially useful in unpacking the language around the commands in the manual. Unfortunately doesn't get around the usb-serial driver issue.

 

[hippy]

Why is the pid bd40 and not 6001?

The bottom line is likely because the AXE027 is an OEM product rather than an FTDI product. Industry and recommended practice is to choose a unique PID which uniquely identifies the product itself rather than the chipset within it. One of the reasons FTDI did so well is they offered this capability when others did not and many still don't.

Having a unique PID means it's easy to recognise an AXE027 as that and not something else. Gives some legal protections if anyone seeks to clone AXE027 cables. It also helps software to identify AXE027 cables from other FTDI devices. And it also helped with ensuring the correct drivers which worked were loaded rather than other FTDI or cloned drivers which did not.

 

[hippy]

This was an isolated case of unnecessary "FTDI fiddling"

'FTDI bricking' was an attempt by FTDI to stop counterfeiters and criminals from profiting from manufacturing and selling fake FTDI chips, making their money at FTDI's expense, reducing FTDI's income which paid staff wages and funded further product development, and protecting their reputation from the damage being done when, what appeared to be FTDI chips, did not function as genuine FTDI chips would have.

What FTDI did wasn't really "bricking" though for many people it amounted to that. What FTDI saw as a legitimate means to counter criminals and counterfeiters was not taken so well by the community which had purchased such counterfeit chips and the backlash caused FTDI to abandon that approach.

 

[bhanlon56]

@hippy
So using a unique pid allows the os to recognize the cable as an axe027. No problem. Could not Microsoft and the linux kernel developers be informed so that the os matches different pids with the same driver so it becomes (in my recent experience) plug and play?

 

[hippy]

Linux embeds the VID:PID pairs it recognises by default into the kernel itself, so one would need to put in a 'pull request' and jump through all the hoops to get Linux approval for achieving that. It may be possible but would likely require someone with previous experience of the process to undertake that.

Microsoft is likely similar, except probably harder to achieve, possibly with certification required, the costs of that plus any fees needing to be paid. As AXE027 drivers, have been a one-off install for most people, with fairly few having problems, there has not been a business case for pursuing that.

 

[kfjl]

The linux FTDI module has 846 vid/pid combinations listed. 0x403/0xbd90 is not one of them.
That's one of the many good reasons to make your own cable.

 

[PhilHornby]

Could not Microsoft and the linux kernel developers be informed so that the os matches different pids with the same driver so it becomes (in my recent experience) plug and play?

If you want to pre-install the drivers, so that the students don't have to, this is possible.
(In an ideal world, they would be added to the image that was used to install Windows on the device, so they're present as part of the "Out of Box Experience", as Microsoft likes to call it).

Failing that, expand out Rev Ed's AXE027.ZIP into a folder and use pnputil /add-driver ftdibus.inf and pnputil /add-driver ftdiport.inf to install the drivers. You can check that the drivers are now in the driver store, using dism /online /get-drivers /format:table|find /i "ftdi".

Once present, plug in the AXE027. That's it!

D:\drivers\ftdi\AXE027_Latest_2.08.14>pnputil /add-driver ftdibus.inf
Microsoft PnP Utility

Adding driver package:  ftdibus.inf
Driver package added successfully.
Published Name:         oem67.inf

Total driver packages:  1
Added driver packages:  1

D:\drivers\ftdi\AXE027_Latest_2.08.14>pnputil /add-driver ftdiport.inf
Microsoft PnP Utility

Adding driver package:  ftdiport.inf
Driver package added successfully.
Published Name:         oem71.inf

Total driver packages:  1
Added driver packages:  1

D:\drivers\ftdi\AXE027_Latest_2.08.14>dism /online /get-drivers /format:table|find /i "ftdi"
oem67.inf      | ftdibus.inf                | No    | USB                   | Revolution Education Ltd       | 18/03/2011 | 2.8.14.0
oem71.inf      | ftdiport.inf               | No    | Ports                 | Revolution Education Ltd       | 18/03/2011 | 2.8.14.0

D:\drivers\ftdi\AXE027_Latest_2.08.14>

 

[system11]

I would say there's a business case for updating the drivers given that so many new PCs have a security feature turned on by default that stops them working. Everything except Windows 10 (for now...) has been aggressively end of lifed. You might even see core isolation becoming a mandatory setting on any hardware that supports it, with no easy way to disable in the near future.

 

[PhilHornby]

The Rev. Ed shipped drivers (2.08.14) are "No Longer Supported" (by FTDI. They weren't even the latest of their kind, intended - as they were - for Windows XP+Vista)

UPDATED - I just noticed that the direct link to the AXE027 drivers results in the above 2.08.14 ... but Picaxe Editor actually ships some slightly newer ones (2.10.0.51), though confusingly, it also includes the older ones as well !?!).

c:\Program Files (x86)\Revolution Education\PICAXE Editor\USB Drivers\AXE027\ =>2.08.14
c:\Program Files (x86)\Revolution Education\PICAXE Editor\USB Drivers\PICAXE Interface = 2.10.0.51

FURTHER UPDATED - The 2.10.0.51 drivers are not properly signed - so can't be used on any modern version of Windows


The FTDI web site says :-

"If a custom vendor ID and/or product ID or description string are used, it is the responsibility of the product manufacturer to maintain any changes and subsequent WHCK re-certification as a result of making these changes. "

So how about updating the AXE027 driver set to the latest version

I think it would be a one-off exercise, because the very latest drivers on the FTDI web site (2.12.36.4) are now 18 months old (and their Release Notes don't actually mention Windows 11). It could be that this hardware is coming to the end of its days ...

 

[hippy]

The Rev. Ed shipped drivers (2.08.14) are "No Longer Supported"

That is true and has been for a very long time. Not being supported does not mean they don't work; it's more that "if you do find a bug with the driver we won't be investigating that". Years of use since we released the AXE027 has shown the 2.8.14 driver to be extremely reliable with all versions of Windows which is why we supply and recommend that version.

The 2.10.0.51 drivers are not properly signed - so can't be used on any modern version of Windows

The 2.8.14 drivers are not signed either and never have been. This has never been a problem because there has always been an option within Windows to always allow installation of unsigned drivers, ask, or to reject unsigned drivers; the default has been to ask so it's a simple "Yes, I want to do that" click when it asks. If anyone has rejected unsigned drivers they will have to temporarily allow them to install the AXE027 but can revert back to rejecting them once done.

I have the 2.8.4 drivers installed on my Windows 10 system and they work well. My understanding is it's no different for Windows 11 but I don't personally have a Windows 11 system I have tried it on. I am sure others have used Windows 11 and installed the drivers without problem.

Getting the drivers signed means paying Microsoft a reasonably large amount of money in up-front fees, plus I believe annual renewal fees and new fees whenever a new OS version comes out. There has never been a business case for signing drivers just to save having to click "Yes, I want to do that" so we have never pursued doing that.

So how about updating the AXE027 driver set to the latest version

There has been no evidenced demonstrable need to given that 2.8.4 drivers have proven so reliable and work to my knowledge on all Windows systems from XP through Windows 11. It would be updating simply for the sake of updating, with all the risks of moving to something which has not had years of proven reliability that 2.8.4 has delivered.

the very latest drivers on the FTDI web site (2.12.36.4) are now 18 months old (and their Release Notes don't actually mention Windows 11). It could be that this hardware is coming to the end of its days ...

I can't imagine that's the case, would expect them to keep making the chips so long as customers are buying them. Even if the chip used does reach end of life it shouldn't be an insurmountable problem.

AXE027 drivers will still be available from ourselves as a download, and included in the PE6 installation, so there would be no issue if the chips were discontinued and someone had an AXE027 which required those.

 

[PhilHornby]

The 2.8.14 drivers are not signed either and never have been.

Those 2.10.0.51 drivers are also signed - but they've been tampered with since they were signed. In this case, the tampering was probably just the addition of the "BD90" identifier to the .inf file.

This has never been a problem because there has always been an option within Windows to always allow installation of unsigned drivers, ask, or to reject unsigned drivers

It's no longer trivial though: See how-to-disable-driver-signature-verification-on-64-bit-windows

Getting the drivers signed means paying Microsoft a reasonably large amount of money in up-front fees

I'm not sure if it does - that might be for the WHQL testing, which isn't required since the binaries haven't been changed. Rev. Ed may have to pay for a 'code-signing' certificate, if not done via Microsoft.

Doesn't FTDI issue any guidance on this subject to its customers?

Here are some Microsoft documents on the subject:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/catalog-files
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/signing-drivers-for-public-release--windows-vista-and-later-

There has been no evidenced demonstrable need to given that 2.8.4 drivers have proven so reliable and work to my knowledge on all Windows systems from XP through Windows 11.

As previously discussed, FTDI have documented several scenarios (within the Release Notes), where these drivers can cause BSODs (with the attendant risk of customer data corruption). IMO, Rev. Ed should not be providing software to its customers, that contains known (potentially dangerous) bugs - relying on the triggering scenario not being encountered.

It may even be, that even be that users have seen these bugs, but the FTDI driver hasn't been named in the summary - one errant piece of software can often interfere with another and cause it to trigger a BSOD.