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

Pages: [1] 2 3 ... 10
 1 
 on: December 03, 2019, 04:13:26 PM 
Started by mc68000 - Last Post by Jaholmes
Hey there, mc68000 - Fellow retro computer engineering hobbyist here. :)  I don't have any schematics to share, but I have a few comments:  First off, the FT245 is a 5V-capable device.  Supply 5V to VCC and VCCIO.  No level translation needed.  Regardless of interrupts, you'll still want a way to poll the FT245 for status, as sending a block of data with interrupts between every byte would be horrendous, performance-wise.  So, map the TXE# and RXF# using a tri-state buffer at some other memory location.  You may have other peripherals with similar needs, so you can probably find things to do with the remaining bits.  /DTACK is a larger topic, but if you're using all reasonably fast peripherals and memories you might get away with simply tying /DTACK to ground, as many others have done in simplistic designs.

If your memory map and selection of peripherals are complex, however, you might bite the bullet and throw a cheap PLD into the mix.  A little will go a long way.  I recently did a 6502 build and fit all the address decoding into a $1.50 22V10 chip.  They're still available from Digikey, and you earn extra 'retro' bonus points by programming them in the ancient CUPL language. ;)

 2 
 on: December 02, 2019, 05:31:45 PM 
Started by Jaholmes - Last Post by Jaholmes
I'm building a USB sensor application using discrete logic--no MCU or CPU.  I have a few candidate designs drawn up, and noticed that I could simplify things if it was permissible to keep WR normally high, then pulse low-high to write.  Datasheets for the FT240X and FT245 are a bit ambiguous about this.  I should mention that I'm also reading bytes, so RD must also being pulsed low-high periodically.  Can this happen while WR is held high--without anything bad happening?  Or must WR be low to read?  I'd guess it would be ok, but figure I ought to put it out there just in case.

Very best,
Aaron

 3 
 on: November 29, 2019, 03:32:10 PM 
Started by asusrog - Last Post by FTDI Community
Hello,

There is nothing in particular with FT230X (vs FT232R) which would cause this issue.
So there must be some issue with your custom PCB.

CTS/RTS flow control signals are used to avoid data loss at high speeds but would probably not avoid data corruption like you are seeing.
Have you wired them up as a test case anyway?

Best Regards,
FTDI Community

 4 
 on: November 29, 2019, 01:00:49 PM 
Started by HASHI4423 - Last Post by HASHI4423
Hi, I am designing a board using FT232HL.

I wanted to use the SPI function, so I connected the EEPROM with reference to the data sheet.

In the reference circuit, it can be read that pull-up resistors on the EECS and EECLK pins are not implemented.
(N.F. = Not Fill ??)

In general, we believe that a pull-up resistor is necessary for level stability of CS.

Is there any reason not to connect?

(Is it pulled up internally?)

 5 
 on: November 28, 2019, 02:26:41 PM 
Started by G40 - Last Post by brenex
Hello,

This issue is caused by other HID class devices connected to the PC.
Did you try disconnecting everything (apart from mouse/keyboard)?

I have a beta for you to try to resolve the issue:

FT_Prog_v0.0.94.440 Installer.zip

Can you please test this out and give us any feedback?

Thanks,
FTDI Community

This fixed the issue for me on Windows 10 64bit

 6 
 on: November 28, 2019, 09:34:12 AM 
Started by asusrog - Last Post by asusrog
Yeah so i tested the hardwired loopback method again on linux and windows and it works fine without any issues. The MCU uart works fine when connected to an FT232RL module but drops frames with FT230xs. Is there anything peculiar about 230xs that is perhaps causing this issue. Does it require connections to RTS and CTS in order to function properly?

 7 
 on: November 27, 2019, 11:53:51 AM 
Started by scorpioprise - Last Post by scorpioprise
Hi everybody,
I have to admit my ignorance, but I asked more experts and I had the following solution.

I was using an external ADC as slave, that was sending me back wrong / corrupted packets.

The Library given (2.5.0) for spi has a bug in spi_readn(), that is the
Code: [Select]
uint8_t FifoScratch[64] variable is not initialized to zero.
Thus, when reading from spi, this leads to a spurious writes where there should be none and, as in my case, the slave recives data when not supposed, sometimes leading to erratic behaviour.
Simple solution, add to the original code, just after the declaration, a 
Code: [Select]

for (int j = 0; j < 64; j++) {
FifoScratch[j] = 0x00;
}
or whatever you like.

Hope this helps future users.

 8 
 on: November 26, 2019, 02:01:54 PM 
Started by asusrog - Last Post by FTDI Community
Hello,

The schematic generally looks ok.

Is the behaviour the same on a Windows PC?

Please test in a loopback fashion to rule out any issue with the communication to the MCU.

Simply connect TXD to RXD and use a terminal program like PuTTY to send/receive characters.
Note that PuTTY will only show received characters unless your force ON the sent characters.

Please also test with our known good hardware which you can also use for reference:

https://www.ftdichip.com/Products/Modules/DevelopmentModules.htm

Best Regards,
FTDI Community

 9 
 on: November 21, 2019, 11:54:09 AM 
Started by asusrog - Last Post by asusrog
I'm working with a custom STM32F429 board, I am using serial-USB port (USART1-PA9,PA10) for debug output and diagnostics. When I connect the board the FTDI chip is recognized and proper kernel modules are loaded.

dmesg output:

[  260.406486] usb 2-1.1: new full-speed USB device number 7 using ehci-pci
[  260.526558] usb 2-1.1: New USB device found, idVendor=0403, idProduct=6015
[  260.526563] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  260.526567] usb 2-1.1: Product: FT230X Basic UART
[  260.526569] usb 2-1.1: Manufacturer: FTDI
[  260.526571] usb 2-1.1: SerialNumber: DN4934JQ
[  261.545819] usbcore: registered new interface driver usbserial_generic
[  261.545829] usbserial: USB Serial support registered for generic
[  261.552062] usbcore: registered new interface driver ftdi_sio
[  261.552086] usbserial: USB Serial support registered for FTDI USB Serial Device
[  261.552266] ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected
[  261.552341] usb 2-1.1: Detected FT-X
[  261.552891] usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0

The problem is that when I use GTK terminal, putty, or moserial to view the datastream, the data is always jumbled up and has missing fields. For example Helloworld\r\n turns to ellwold\r\n. Inited Can Bus at bitrate 125000 bps turns to Initd aus a birate 500 ps. I have attached the relevant schematic here. I have basically copy-pasted the self-powered USB design from the datasheet for FT230XS.


You might notice that there are no decoupling caps on the VCC pin as shown in the datasheet. Connecting 2x 100nF and 1x 4µF caps on this pin was causing an error where the chip couldn't be read by the Linux kernel.

[ 4135.146806] usb 2-1.1: new full-speed USB device number 45 using ehci-pci
[ 4135.226834] usb 2-1.1: device descriptor read/64, error -32
[ 4136.187078] usb 2-1-port1: Cannot enable. Maybe the USB cable is bad?

Also I have configured the CBUS0 pin for VBUS_SENSE via the FT_PROG utility. Any suggestions or tips would be greatly helpful as this is my first project with any FTDI chip.



I have experimented with different baud rates and tried various combinations of decoupling caps on the vcc to check if this is a power stability of signal integrity issue. I have tried removing the microcontroller out of the picture by doing a hardwired loopback but i dont get any echo. I have replaced the ic to rule out the possibility of a faulty chip.

 10 
 on: November 18, 2019, 09:58:28 AM 
Started by nevs - Last Post by nevs
OK, when I use libMPSSE__0_6_Beta.zip everything works... ;D

Pages: [1] 2 3 ... 10