FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team @ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - FTDI Community

Pages: 1 ... 24 25 [26] 27 28 ... 60
376
Discussion - Hardware / Re: FT2232H Channel B GPIOs Hold State while Channel A in Sync FIFO mode?
« on: December 21, 2020, 11:56:33 AM »
Hello,

Yes you can find details of the behaviour of the Port B lines in chapter 4.13 of this datasheet below:

https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf

Hope it helps,

Best Regards, FTDI Community

377
Discussion - Hardware / Re: FT232H Module not detecting
« on: December 17, 2020, 11:58:12 AM »
Hello,

Did you attempt to remove these components on a fresh board, or a board that was already presenting the issue?

Could you clarify the voltages for VCCD and VCCIO on a working and non working board?
Also please let me know if there are any signs of damage or burning on the IC once the issue appears.

Your schematic doesn't look to have any issues, but can you clarify if the FT232H is connected to a target when the issue occurs?

The lack of crystal oscillation indicates that the host machine has not enumerated the IC.
Please use our MicrosoftUSBView utility, and take a screenshot of the output for a device which is showing the issues.

Best Regards,
FTDI Community

378
Discussion - Drivers / Re: What says FT_DEVICE_LIST_INFO_NODE type?
« on: December 16, 2020, 04:38:59 PM »
Hello,

This information is proprietary to FTDI.

You can read the product description to determine the product type.
The default product descriptions can be found below:

FT232R USB UART
FT245R USB FIFO

The other option you have is to program a unique serial number or description to help you distinguish between the two device types.

Best Regards,
FTDI Community

379
Discussion - Drivers / Re: VCP driver on macOS 11
« on: December 16, 2020, 12:51:06 PM »
Hello,

Here is the entry for the device with the 0xEEEF product ID:
Code: [Select]
<key>microHAM USB Port</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>idProduct</key>
<integer>61167</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>
And for reference here is a standard FT232R device:
Code: [Select]
<key>FTDI R Chip</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>bcdDevice</key>
<integer>1536</integer>
<key>idProduct</key>
<integer>24577</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>
The Microham device hasn't defined any special settings for latency timer, buffer sizes of buad rate aliasing, which is where my original comment stems from. However the have omitted the bcdDevice field which may cause issues depending on which IC they are using. If they are advising their software wont work when the FTDI defaults are used then I would stick with this advice. But in general as a stop gap solution it is perfectly fine to re-program a device to use FTDI defaults.

Best Regards,
FTDI Community

380
Discussion - Hardware / Re: Questions on ft4232h to rs485
« on: December 15, 2020, 04:40:56 PM »
Hello,

In order to configure TXDEN, an external EEPROM is required:

* RI#/ or TXDEN is selectable in the EEPROM. Default is RI#.

I can provide the USB-COM485-PLUS4 if you contact us via email:

https://www.ftdichip.com/FTContact.htm

RS485 systems often have local echo enabled. This means any data transmitted by a device is echoed back to itself.

There is a hardware option to disable local echo on the USB-COM485-PLUS4. Please refer to the USB-COM485-PLUS4 Datasheet.
Connect pin7 and pin 8 can disable the local echo function. The local echo is enabled by default.

Best Regards,
FTDI Community

381
Discussion - Drivers / Re: Does D3XX driver support ARM ?
« on: December 15, 2020, 04:38:06 PM »
Hello,

We have beta ARM Linux drivers available.

Please contact us via email and we can provide a link:

https://www.ftdichip.com/FTContact.htm

Best Regards,
FTDI Community

382
Discussion - Hardware / Re: FT232H Module not detecting
« on: December 14, 2020, 04:17:32 PM »
Hello,

Thank you for the schematic, after a quick review I cannot see any glaring issues.

Can you try removing D2/D3 on the USB data lines and let me know if the device enumerates?
Are either R7 or R5 populated? and just to clarify there are no physical signs of damage to the IC?

Best Regards,
FTDI Community

383
Discussion - Software / Re: FT4222 FT_OpenEx with FT_OPEN_BY_LOCATION
« on: December 14, 2020, 03:48:27 PM »
Hello,

I doubled checked this on my Windows 7 machine and the LocID is appearing correctly for the FT_GetDeviceInfoDetail API call (see attached image).

I have also attached an image of our USBView utility showing the location of the attached device (loc112).

The LocID is reported by the host machine, can you double check with USBView what location ID your device is reporting?


Best Regards,
FTDI Community

384
Discussion - Hardware / Re: FT232L Hangs after running for hours
« on: December 14, 2020, 03:37:39 PM »
Hello,

An IO error usually indicates some kind of hardware issue which has caused a disconnect of the USB line. This could be noise from your attached serial device or a dip in the power supply etc. it is worth checking that your RS485/422 device does not cause any noise on the lines. If you use half duplex RS485, also check that your RPi and your other serial device don't try to send at the same time as this can cause collisions on the line.

As you said, the delays can vary depending on the USB scheduling and the application itself which sends and receives the data may also be subject to varying latencies in the operating systems itself.

Best Regards, FTDI Community

385
Discussion - Drivers / Re: VCP driver on macOS 11
« on: December 14, 2020, 03:22:34 PM »
Hello,

I've doubled checked the above Product ID in the info.plist file and it looks like there are no special settings being used for this device. As such programming the device to use its Default product ID would all you to use it with the inbuilt Apple VCP driver. Are you aware of which FTDI product this device uses?

I've had an update from the developers, and they are currently working on resolve signature issues with the .dext driver package.

Best Regards,
FTDI Community

386
Discussion - Software / Re: How to Read-Write on FT220X via FTD2xx lib?
« on: December 11, 2020, 05:54:36 PM »
Hello,

There is example source for an FT1248 application in the following:
https://www.ftdichip.com/Support/Documents/AppNotes/AN_173_Establishing_FT1248_Communications_using_a_Morph-IC-II.pdf

For the write routine in this application it will buffer up 2 bytes of 0x00 before the byte to be sent to the target device, this buffer of bytes is then written out with FT_Write.

Best Regards,
FTDI Community

387
Discussion - Hardware / Re: FT232H Module not detecting
« on: December 10, 2020, 04:17:20 PM »
Hello,

Would you be able to provide the exact schematic you used in your design?
And are you noticing any signs of burning on the IC after it fails to enumerate?

Best Regards,
FTDI Community

388
Discussion - Software / Re: Zeros in output from FT220X (C#)
« on: December 09, 2020, 05:40:33 PM »
Hello,

It was more in relation to the prinft statement using the unsigned long identifier, and not how the rxBuffer is defined.

Can you take a logic capture of the device receiving this data?

MIOSIO[0] is the bi-directional data line, which the master must read or write to.

Best Regards,
FTDI Community

389
Discussion - Software / Re: Zeros in output from FT220X (C#)
« on: December 08, 2020, 05:16:20 PM »
Hello,

Thanks for your code, I cannot see any glaring issues with it immediately.

However I did notice you are trying to print the 'RxBuffer' data as a unsigned long:
Code: [Select]
printf("Data Recieved: 0x%lu\n", RxBuffer[i]);
But RxBuffer is defined as a char array.

Could you also double check the data being received by the FT220? I.e what is the expected 4 bytes?

Best Regards,
FTDI Community

390
Discussion - Software / Re: Zeros in output from FT220X (C#)
« on: December 07, 2020, 02:03:39 PM »
Hello

Thank you for your update.
There is no encryption used on the FT220X, what API call are you using when the following happens:
 
Quote from: 9ghtX on December 07, 2020, 05:18:08 AM
Also I notice that this values have difference in 12. If I printf() them in %lu, I get RxBytes: 0x6421720, TxBytes: 0x6421732 and RxBuffer: 0x6421444. Is this kinda encrypting? And if this packages always change and they are encrypted, how I can uncrypt them?

Can I see this code snippet?

Best Regards,
FTDI Community

Pages: 1 ... 24 25 [26] 27 28 ... 60