FT2232HL JTAG Interface w/ UART? - Page 1
Forum section: electronics / general

author: gnuarm
author_rank: Super Contributor
timestamp: February 14, 2021, 09:00:14 pm
content: We are adding a FT2232HL JTAG interface chip to a board being designed to program the FPGA. It will only be added on the prototypes and not assembled for production saving the cost of the programming cables for every developer which are not cheap.The guy programming the MCU has asked to share the JTAG interface, so it will use a buffer chip and a jumper to select which device the four JTAG pins connect to.The software guy has also asked to use the serial port that the FTDI chip may or may not have. I'm not familiar with this JTAG device at all. Just as important is the driving software. Does anyone know if this chip can be used for both JTAG and serial port operation without a lot of hassle, like switching between drivers or what ever? Is this a reasonable goal?

author: sicco
author_rank: Regular Contributor
timestamp: February 14, 2021, 09:30:05 pm
content: The FT2232H is not a JTAG interface chip, but it can be used as JTAG interface chip. There are application notes on the FTDI websitehttps://www.ftdichip.com/Support/Documents/AppNotes/AN_129_FTDI_Hi_Speed_USB_To_JTAG_Example.pdfon how to use it as JTAG USB interface. The FT2232H has by default two serial ports. They will show up (get enumerated) as COMX and COMY, for example COM12 and COM13 when the USB is plugged into your PC. One of these two, the lowest, or the 'A' port, can be used in ' MPSSE' mode. Once that's enabled, it will no longer be a COMX serial port (UART), but instead be enabled to do high speed clocked bit streams, synchronously (clocked) instead of asynchronously, in and out. With long words. Like 32 bits instead of ~8 bits/character for a normal serial port. And with that the JTAG interface can be made to work. The FT2232H port A pins are used for both the 'normal' serial port function and for the MPSSE mode. You thus rule out that it's both JTAG and serial port at the same time. However, the port B can remain serial port while the port A does MPSEE for JTAG. For MPSEE to work, you need the right driver (FTD2XX.DLL, .LIB, 32 vs 64 bits hassle...).The serial ports typically work with standard serial port USB drivers.(I just went through the hassle of making a legacy BDM interface for the legacy the mpc8xx PowerPCs in the Tek TDS3000 scopes - BDM is a bit like JTAG - but different again...)

author: langwadt
author_rank: Super Contributor
timestamp: February 14, 2021, 10:36:00 pm
content: Quote from: gnuarm on February 14, 2021, 09:00:14 pmyes you can use MPSSE (JTAG) in one port and serial in the otherwith the right eeprom config you can also use the fast synchronous fifo mode in port and Aand MPSEE in port B

author: RoGeorge
author_rank: Super Contributor
timestamp: February 14, 2021, 10:45:04 pm
content: Quote from: gnuarm on February 14, 2021, 09:00:14 pmUsually there is no need to use separate connectors for each JTAG chip. All chips can share the same connector without any additional buffers.https://www.fpga4fun.com/JTAG1.html

author: gnuarm
author_rank: Super Contributor
timestamp: February 14, 2021, 10:53:46 pm
content: Thanks for your reply, very informative. The design is copied from the eval board for the Gowin FPGA. They provide a driver with their software. So I guess it is up to the software if it supports the serial port at the same time. That's what I needed to know. Now I just need to figure out the pins to use for the serial. I expect I can find that.A similar board using this part in a different package adds the EEPROM, but I don't know why that would be needed. The Gowin board doesn't have it. Ahhh... looking at the data sheet for the chip table 4.11 shows the modes that can be configured from the driver vs. the EEPROM. Looks like we need to add the EEPROM for the async serial port.

author: gnuarm
author_rank: Super Contributor
timestamp: February 14, 2021, 10:57:27 pm
content: Quote from: langwadt on February 14, 2021, 10:36:00 pmLooks like an EEPROM is needed for the serial mode, right?

author: gnuarm
author_rank: Super Contributor
timestamp: February 14, 2021, 11:03:37 pm
content: Quote from: RoGeorge on February 14, 2021, 10:45:04 pmIn theory... That requires the software to be aware of the other device and skip it as all the devices are daisy chained. That doesn't always work out, at least not in the FPGA world. A jumper is fine. I'll use the FPGA driver and the software folks can use their drivers. Better than two chips. I'm not sure why he wants the JTAG. He has the SWD port... on a 20 pin connector! lol But I guess they each have their advantages.

author: RoGeorge
author_rank: Super Contributor
timestamp: February 14, 2021, 11:17:55 pm
content: Quote from: gnuarm on February 14, 2021, 10:57:27 pmThe FTDI chip has an internal EEPROM and specific tools (from FTDI) to program it.Quote from: gnuarm on February 14, 2021, 11:03:37 pmNo. JTAG devices can be chained, this feature is in the JTAG specifications, and all compliant JTAG software knows how to deal with that. The word "Usually" I used at the beginning of my sentence was about something else.

author: gnuarm
author_rank: Super Contributor
timestamp: February 14, 2021, 11:25:24 pm
content: The Trenz board uses six additional pins to the FPGA and the EEPROM. I see the somewhat sparse documentation says it supports both "JTAG and UART over Micro USB2 connector".https://wiki.trenz-electronic.de/display/PD/TEC0117+TRMhttps://shop.trenz-electronic.de/trenzdownloads/Trenz_Electronic/Modules_and_Module_Carriers/2.5x6.15/TEC0117/REV01/Documents/SCH-TEC0117-01.PDFI will use that design as a guide.Anyone know if this requires preprogramming of the EEPROM or a special driver? I don't see a mention of a driver but I haven't gone through the software as yet. Is the EEPROM programmable via the USB port?

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 12:40:30 am
content: Quote from: gnuarm on February 14, 2021, 10:57:27 pmI didn't think it was needed, but it looks like it in the table.I know it is needed for the sync fifo mode, but you can change the mode afterwards with software

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 12:43:09 am
content: Quote from: gnuarm on February 14, 2021, 11:25:24 pmthe eeprom can be programmed via USBthe FTDI drivers come with both windows an linux

author: gnuarm
author_rank: Super Contributor
timestamp: February 15, 2021, 06:55:00 am
content: Thanks. I've sent the info on to the software guy who wants the serial port. I'll let him work out the software details since it's his need and his domain.

author: RoGeorge
author_rank: Super Contributor
timestamp: February 15, 2021, 11:56:24 am
content: If you are the one doing the hardware, than you should provide on the PCB one JTAG connector and another connector for a serial port. These two connectors must be on all boards, not only the development ones.The JTAG is used to program and/or debug all chips supporting JTAG from your board (all at one JTAG connector only, so you can access them without switching connectors or jumpers). The COM port (serial) is used to send receive whatever data you need, for example to talk with the UBOOT or to SSH in Linux, etc.A single FTDI chip can provide 2 "channels" (see the datasheet), that is why both the JTAG and the COM interfaces can be handled by a single FTDI. This dual function is not critical, one can use as well two distinct programming cables, one USB to JTAG and one USB to serial.That is why two connectors are needed, one JTAG and one serial connector (just the pins from the serial port of your chip, not the +/-12V RS232 level buffers like in a PC, but the same voltage as the rest of the JTAG, unless it was specifically requested to be RS232). However, the connector's holes are needed on all boards. You can leave the connectors unpopulated for production boards, and use pogo pins to program them, or use preprogrammmed chips, but the JTAG and COM holes must be available on all boards, development or production.The FTDI chip with the USB (JTAG+COM) is usually sitting on the programming cable, not on the PCB. You can either buy a FTDI JTAG cable and reprogram it, or make your own FTDI to JTAG on another small board attached to an USB cable, for the FT2232 alone.What you see on devboards, where the FTDI chip (the programming cable) is included on the same PCB as the demo chip is an anomaly. That method is used for learning purposes only, because the student might not have a JTAG cable and might not know how to connect it to the board (some JTAG cables have DUPONT wires you plug one by one in the JTAG pins of the board).You can always buy a ready-made JTAG cable for whatever processor or FPGA you are using, otherwise you will need to "steal" the EEPROM content for your JTAG, because most of the proprietary IDE/toolchain will accept only their proprietary JTAG cable. Do not use stolen software for your job. Buy the darn cable and forget about the FTDI part. Just add the two JTAG and serial connectors on the board, that's all.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2021, 03:26:35 pm
content: Sorry if I've missed it, but what's the chip you want to access through JTAG? As said above, the FT2232HL can be used as a JTAG adapter (and it's very common in many JTAG adapters actually), but of course, software support must exist for the particular chip you're using. Else you may have to implement that yourself, doable, but which may not be what you intended. So knowing what chip it is is definitely required.Then a couple remarks: yes the FT2232HL will require an external EEPROM - configured with the FT_Prog utility. The default behavior for the FT2232H, without EEPROM (or blank EEPROM) is, IIRC, two serial ports? To be able to use it in other modes, you need to configure it. Again IIRC, The port you want to use for JTAG must be configured as "FT245" (and then the software takes care of the rest). If it's not in FT245 mode, I don't think software can program it for JTAG. I may have mixed up the default settings though (from bad memory), but either way, I'm pretty sure you'll need to configure the EEPROM for a combination of 1 channel JTAG and the other UART.The other related note is that of course you can absolutely have UART plus JTAG. The FT2232H has two ports. One can be used as JTAG, the other as UART. That again must be configured properly (once) with FT_Prog. This combination is again pretty common in JTAG probes, and even more so on FPGA dev boards. For a simple schematic of that, you can take a look at the schematic of the breakout board for the Lattice MachXO2 for instance.

author: Bassman59
author_rank: Super Contributor
timestamp: February 15, 2021, 05:24:42 pm
content: Quote from: RoGeorge on February 15, 2021, 11:56:24 amTHIS.For production, where you don't know who will be programming the boards after they are assembled, the best way to ensure success is to provide documentation that says, "Use Vendor Software XYZ and Vendor Programming Pod ABC to load the binary image."

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 05:36:50 pm
content: Quote from: SiliconWizard on February 15, 2021, 03:26:35 pmJTAG is MPSSE you can switch between UART and MPSSE with software don't need to program the EEPROMFT245 Style Synchronous FIFO is special you must have an eeprom to use that but you can still switch port B to MPSSE in software

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2021, 05:59:35 pm
content: As I said, I was challenging my memory on this, but I still thought you needed an EEPROM for having both an UART AND MPSSE, and after re-reading the datasheet, it sounds right.- You're right, MPSSE itself doesn't need an EEPROM and can be software configured without one.- BUT as far as I got it, getting a port in UART mode requires an EEPROM. All you can do in software is to set the baudrate, but software only can't configure a port in UART mode without an EEPROM.The table from the DS can be found in "4.12.1 Do I need an EEPROM?"

author: fchk
author_rank: Frequent Contributor
timestamp: February 15, 2021, 06:04:46 pm
content: Quote from: gnuarm on February 14, 2021, 09:00:14 pmYou could also use the FT4232HL (which has the same pinout and is only a little more expensive), connect Port A to the FPGA JTAG port, Port B to the uC JTAG Port and still have Port C and D free as UART ports. I've done just that in one of my recent designs. OpenOCD works just fine, and also the Lattice Standalone Programming tool works with this setup.Another way is daisy-chaining the JTAG devices (programmer TDO to the TDI of the first device, TDO of the first device to TDI of the second device, TDO of the second device to TDI of the programmer), if the software supports this.

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 06:16:44 pm
content: Quote from: SiliconWizard on February 15, 2021, 05:59:35 pmthe table must be wrong or confusinghttps://www.ftdichip.com/Support/Knowledgebase/index.html?98installingft2232cdevices.htm" If no EEPROM is fitted, the device will default to both channels configured as USB to UART interfaces using VCP drivers. "

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2021, 06:40:15 pm
content: Quote from: langwadt on February 15, 2021, 06:16:44 pmIt is not. You're confusing the FT2232H, which is a USB 2.0 HS device, with the FT2232C, which is much older.

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 07:24:59 pm
content: Quote from: SiliconWizard on February 15, 2021, 06:40:15 pmit is the same for the FT2232H, from the datasheet (page 27):"If no EEPROM is connected (or the EEPROM is blank), the FT2232H will default to dual serial ports. Thedevice uses its built-in default VID (0403), PID (6010) Product Description and Power Descriptor Value.In this case, the device will not have a serial number as part of the USB descriptor."

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2021, 09:42:58 pm
content: This statement is confusing compared to the table. I don't have a device around without an EEPROM that I could quickly test, so I can't check.But I can tell you what is a configuration that I know works, that is what's done on Lattice boards, and what I've done with my own adapters, and I've made a few with the FT2232H.EEPROM configuration is as follows (as set with FT_Prog - I had actually extracted this from a Lattice breakout board):* Port A: (for JTAG)- Hardware: 245 FIFO- Driver: D2XX direct* Port B: (fort UART)- Hardware: RS232 UART- Driver: Virtual COM PortI can certify 100% that the above configuration works as intended, and that it's very likely NOT the default configuration.I could give no guarantee at all about any other configuration. I've never tried, but I would have doubts.I suspect (without being certain) the default for both ports is like how Port B is set up above, and I doubt (without being certain) that the same setup for JTAG access would work. Again, I can just tell what I definitely know will work. And I don't think risking a dead board is worth saving a few cents for the small required EEPROM. Now if someone has actually made the JTAG+UART configuration work with an FT2232H with the default config, please chime in. If not, I would tend to stick to what I know works instead of risking interpreting documents. Just my 2 cents.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 15, 2021, 09:58:05 pm
content: FT2232H is the same as two FT232H. Each may be configured independently. There are two types of drivers - VCP (serial) and FT2XX (may work in different modes including MPSSE for JTAG, but not VCP). If the device is taken by VCP driver, it cannot be used for FT2XX purposes and vise versa. As I remember, the driver used for the specific device must be specified in EEPROM.Your FPGA may support talking through JTAG, in which case the second half of FT2232H for serial is total waste, and a single FT232H with a single connector will work just as well.JTAG must supports a chain of devices. TDO of one goes to TDI of the other, making a huge shift register. Any JTAG software should support this. Not to mention that if you write your own, it's totally up to you what to support. Supporting a chain will require very little effort.Software tools may require a license in EEPROM to use their software. Vivado is one of such tools. You cannot buy the license, only with their own programming cable. If you write your own software through MPSSE, this is not a concern - hardware doesn't require a license.

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 10:03:44 pm
content: Quote from: SiliconWizard on February 15, 2021, 09:42:58 pmI suspect the table is to interpreted as the modes you can make the part plug as by programming the eeprom and the modes you need to enable via software after pluggingyou config doesn't make sense because JTAG is done with MPSSE (but that can always be enabled via software)245 FIFO is an 8bit parallel interface, that can be enabled via software but only after it has been enabled in eepromI've done FPGA configuration with MPSSE JTAG on port B and then after configuration enabled sync fifo on port A, that requires an eepromI think I have an FT2232 mini module somewhere, if I can find I'll try if it work as jtag and uart with out eeprom

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2021, 10:15:19 pm
content: Quote from: langwadt on February 15, 2021, 10:03:44 pmIt's 100% guaranteed to work. I would almost bet 1 million dollars on it.The configuration of those chips is a bit confusing. Enabling "245 FIFO" in the EEPROM configuration actually makes the chip usable for many other modes, including MPSSE.The available "hardware" config in FT_Prog are the following: "RS232 UART", "245 FIFO", "CPU FIFO" and "OPTO Isolate". Now what would make you think any of the other modes would make more sense for MPSSE? And AFAIR, if you set the chip for "RS232 UART" (which I think is default?), I'm not at all sure you can use MPSSE. To be confirmed.And anyway, as I showed above but NorthGuy confirmed, I don't think you can use MPSSE with the VCP driver anyway - which, again, I think is default (TBC as well). So...

author: langwadt
author_rank: Super Contributor
timestamp: February 15, 2021, 10:24:15 pm
content: Quote from: SiliconWizard on February 15, 2021, 10:15:19 pmI don't doubt that it works, I think MPSEE can always be enabled. Setting 245 fifo mode might just be a way of avoiding the OS loading the VCP driver

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 15, 2021, 10:27:27 pm
content: Quote from: langwadt on February 15, 2021, 10:24:15 pmNo, this last point is handled separately in the EEPROM config, as I showed above. There is a specific setting for the driver you want the OS to load, for each channel: D2XX or VCP. This is completely separate. For instance, you can use the chip in FT245 async FIFO mode (parallel bus) with the VCP driver. Conversely, you can use it in UART mode with the D2XX driver. But for special modes such as MPSSE or synchronous FIFO, you can't use the VCP driver AFAIK.Maybe MPSSE can be used if the channel is set as RS232 UART and D2XX as well, I don't know, haven't tried. But you'd still need to configure the driver option using an EEPROM.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 15, 2021, 11:01:18 pm
content: From FTDI programming manual:"For Linux, Mac OS X (10.4 and later) and Windows CE (4.2 and later) the D2XX driver and VCP driver aremutually exclusive options as only one driver type may be installed at a given time for a given device ID.In the case of a Windows system running the CDM driver, applications may use either the D2XX or VCPinterface without installing a different driver but may not use both interfaces at the same time."

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 16, 2021, 02:00:00 am
content: Quote from: NorthGuy on February 15, 2021, 11:01:18 pmI was going to talk about Linux, and this statement is not as easy to understand as it looks.I have some experience with FTDI devices on Linux, and there is actually no specific driver for them. Not in the true sense. FTDI parts are accessed through libusb on Linux.The Linux "driver" provided by FTDI is actually just a user-mode library giving D2XX functionality to applications using itself libusb to access the device. This is not really a driver per se.Then, the equivalent of "VCP" on Linux is also built in the Linux kernel. There's nothing to do or to install for this. You plug the device, and virtual serial port(s) are created. You don't need any software from FTDI for serial port-only functionality. As to the equivalent of D2XX access, there is an open-source alternative called libftdi. It has a slightly different API, but basically gives the same functionality - although I don't know how much of MPSSE it provides.The headache is that, on Linux, the EEPROM configuration for drivers is IGNORED (as opposed to Windows). So by default, any FTDI device will be enumerated on Linux as a USB serial device.AND, yes, once they are tied to serial ports, you cannot use the D2XX access (which is the only way to get access to any other mode than UART). Which is really annoying. The solution is to add a udev rule to automatically detach the device from the created serial port(s) so you can use D2XX on it. If the device has an EEPROM with a specific USB VID/PID, then it's annoying, but just requires this specific rule. If the device OTOH has the standard FTDI VID/PID, then it becomes intractable: if you add such a rule, it will apply to ANY device with the default VID/PID. Which may not be what you want.AFAIK, the same applies to MacOS, as last time I checked, it was also based on libusb on it.On Windows, the driver selection in EEPROM is used, and thus you can choose which will be loaded, even per channel!So on Linux(/MacOS), the only solution if you want D2XX access, and not infuriate your customers by blocking all other devices they might use that are FTDI-based with the default IDs, is to program your own VID/PID. Assuming you have a VID. Which is costly. A free option is that FTDI can give you a few dedicated PIDs, and you can still use FTDI's VID. A few years ago, that was a free service, and I made the query. I got 8 dedicated PIDs. But given the scarcity of PIDs (they are only on 16 bits!), I don't know if FTDI still provides this service.

author: djacobow
author_rank: Super Contributor
timestamp: February 16, 2021, 03:36:56 am
content: Quote from: SiliconWizard on February 16, 2021, 02:00:00 amIt just so happens that I've been up to my eyeballs in the FT232H and the FT4232H, on linux, for the past few weeks, and this does not match my experience. What I observe happening on ubuntu is that the devices enumerate into serial ports, but that any software that wants to put them into MPSSE mode just does that and the serial port disappears at that instant.I've been working with the PyFtdi drivers, which put a python wrapper around libusb and which generally use MPSSE and provide functionality for JTAG, SWD, I2C, and SPI. Oh, and simple bitbang GPIO. The only udev rule I have is one that sets the permissions for the devices to 0777 based on the VID/PID. My programs can then open the ports in whatever mode I want. I can attest that SWD, I2C, SPI, and GPIO all work. I haven't tried regular JTAG. This is all using custom python code except for SWD, which we're using with OpenOCD. My company has a design where we use the 4232 (a four port chip) to do SWD, SPI, I2C, and UART all at once. On the 4232 only the first two ports can do MPSSE, so the I2C is bit-banged.The chip, in many ways, is magic for us. (If only it supported 1.8V IO) It costs about $8-10 bucks in single-digit quantities (we use it in program/test fixtures) so it's not cheap, and in theory, and microcontroller could do what it does, but I guess you're paying for the libraries.The EEPROM is optional, by the way. If present, you can use it to set a different VID:PID, serial number, and default modes, but the operating modes can be overridden at runtime, and if you don't have the EEPOM, it just shows up as four serial ports first, but then you can switch things up as you need.

author: gnuarm
author_rank: Super Contributor
timestamp: February 16, 2021, 04:03:03 am
content: Wow, this thread got a lot of action today.Quote from: SiliconWizard on February 15, 2021, 03:26:35 pmThe whole reason for putting this chip on the board is because we want to avoid having to buy programming cables for the Gowin FPGA at $80 each, plus all the extra costs in the EU/UK. The design was lifted from a Gowin eval board for their device.There is a second FPGA board design from Trenz which is very similar, but they appear to support the UART by tying six signals from the B port to the FPGA and adding the EEPROM. One of the FPGA designers is using a UART, so nice if we can get it all over one USB cable.Since the JTAG support in on the board, the MCU guy wants to be able to use it as well. He also wants a UART for the MCU, so why not this one? It is doubtful both FPGA and MCU will be debugged together much. Well, in my experience FPGAs require a lot less debugging on the bench because of the extensive simulation.Connectors will be added to support direct connection of cables in place of this chip because we don't plan to add the chip for production.QuoteLooking at the manual, the EEPROM is needed for ASYNC Serial UART mode. The EEPROM is not needed for the MPSSE mode.QuoteGood to know. Thanks I see the XO2 schematic shows what pin is what serial port function. I needed that!

author: gnuarm
author_rank: Super Contributor
timestamp: February 16, 2021, 04:36:27 am
content: Quote from: fchk on February 15, 2021, 06:04:46 pmI would love to use a 4 port device, but we are trying to develop a ventilator with a diverse team who have varying skill sets. Heck, one guy they picked for FPGA work can't get the Lattice tools licensed! So it will be better to use a design known to work since the big wildcard in all this is the Gowin software.For the same reason, no chaining of JTAG devices. Keep it simple and get the job done.

author: gnuarm
author_rank: Super Contributor
timestamp: February 16, 2021, 04:38:14 am
content: Quote from: langwadt on February 15, 2021, 06:16:44 pmPerhaps the key there is "using VCP drivers"? Is the MPSSE mode compatible with the VCP drivers?

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 16, 2021, 03:11:27 pm
content: Again, I told you what I know works. Now do as you wish if saving the cost of a very small EEPROM is worth any potential future trouble. If anything, give provision for the footprint on your PCB, and if after good testing you realize you can do without it, just don't populate it. As I said, I think the VCP driver is default on Windows - to be checked, but it would make sense - and I don't think you can use JTAG with the VCP driver, so that would be end of the story. The the only way to circumvent that would be to bug your users with annoying hand-installing of drivers to replace the VCP one. Very annoying.The MachXO2 board I mentioned has an EEPROM too. They probably wouldn't have bothered if it was not needed, it was a very cheap (at the time) board. (And no, they don't use any specific VID/PID, and the device string doesn't matter for Lattice tools as far as I've tested, so that was not the reason either.)As I think someone suggested, if you really want to be sure and make the right decisions for your needs, just buy a breakout board for the FT2232H (there are a handful of them available for cheap), experiment, then decide.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 16, 2021, 03:16:44 pm
content: Quote from: djacobow on February 16, 2021, 03:36:56 amIt's impossible to do this without the appropriate rights on Linux. So the program doing this would need elevated rights. Maybe that's what Ubuntu does with the tools you're using, although I consider this bad practice for security reasons. The simplest and safest way is to use a udev rule.But yes, you can detach the device from the serial ports "manually" (so any program could do this as well) - I don't remember the exact procedure, but you need to send a specific value to a specific dev path, and again, with the appropriate rights. With basic user rights, that won't work.Since that was a long-time problem with FTDI devices, maybe FTDI has added this feature in recent versions of their Linux "driver" (but I insist, tha would require to give the program proper rights.)There are a lot of articles on this issue over there. One of them:https://stackoverflow.com/questions/33649296/how-can-i-get-linux-device-with-ftdi-d2xx-driver-api

author: djacobow
author_rank: Super Contributor
timestamp: February 16, 2021, 08:12:31 pm
content: Quote from: SiliconWizard on February 16, 2021, 03:16:44 pmThis is the only FTDI-specific udev rule I have added to my system:Code:ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6011",MODE="0777",GROUP="dialout"ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001",MODE="0777",GROUP="dialout"With these rules I can open the devices serial ports as a regular user member of the dialout group, and I can also use them in MPSSE or GPIO mode using OpenOCD and PyFTDI.I guess other users could do the same, so I suppose that is a security issue if you have other users.By the way, I don't have EEPROMS on any of my boards. The EEPROM is really just a convenience, nothing more. You just don't need it. I would say, however, that it would be convenient to have serial numbers and a few other EEPROM features, and for that reasons I have designed in the EEPROM for the next rev of our board.