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: October 23, 2019, 09:42:45 AM 
Started by dania - Last Post by dania
Hello,

time between end of transmit and disasserting SS is several miliseconds. It's possible to shorten it?

 2 
 on: October 23, 2019, 08:34:26 AM 
Started by baum - Last Post by baum
Hi,

I am using the D2XX software with a FT2232H which operates in the synchronous fifo mode. When I call the FT_GetStatus
function the number of bytes in the transmit queue are always reported as zero. I even disabled the logic which will read
from the fifo in FT2232H and after writing bytes to the FT2232H via the FT_Write function, the  FT_GetStatus function still
tells me there are no bytes in the transmit queue. I have no problems with the FT_GetQueueStatus function and the
FT2232H works as expected so far. Is there a software switch which will enable FT_GetStatus function to report the
bytes in the transmit queue or is it a feature of the DX22 software not reporting the  bytes in the transmit queue.

Regards,
Robert

 3 
 on: October 22, 2019, 04:30:59 PM 
Started by Yunuce - Last Post by FTDI Community
Hello,

It sounds like a problem with your custom hardware.

Also, VID_0000&PID_0002 doesn't match to what the FT905 is associated with.

What firmware is the FT905 running? Have you tried restoring the bootloader using the FT9xx Programming Utility found on your desktop as part of the FT9xx Toolchain?
Which silicon revision are you using? Rev B or the latest Rev C?

Please email your schematics to your local support team for review:

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

Best Regards,
FTDI Community

 4 
 on: October 22, 2019, 10:19:05 AM 
Started by atom1477 - Last Post by atom1477

Perhaps due to unaligned read/write.

Not only. USB side of FTDI sends data to PC serially, not parallely.
So even when data is written to FTDI aligned (32 bit), it may disappears from FIFO byte by byte.
When I write alligned 1024 words of 32 bits, I fill all the FIFO. But FIFO will be send
via USB byte by byte, right?
It depends on what FIFO occupancy meter is used.
TXE_N indicates 1 byte, and nonaligned writes are supported, so I guess that meter is 1 byte, and counts to 4095. Every 32-bit (aligned) write to FTDI increase FIFO occupancy by 4. But continuous transmission via USB will decrease FIFO occupancy by 1 or by 4. It depends on FTDI hardware, which is not described in datasheet.
If it decreased by 1, it will cause issue that I asking for. Even when I write only aligned 32-bit data, FTDI
may sends it byte by byte indicating 1 byte free space in FIFO.
In this situation TXE_N
is useless, because it don't give enough information to next 32-bit aligned write. To do 32-bit writes, a 4-bytes free space information is necessary.

But in Your scenario, when nonaligned writes are made, the same issue appear even when USB transmission decreasing FIFO occupancy by 4.
So I'm surprised that You made TXE_N as 1-byte free space indicator, not as 4-byte free space indicator.
Unless it's a datasheet error and it's actually a 4-byte indicator. So I ask about that.

 5 
 on: October 21, 2019, 04:18:01 PM 
Started by atom1477 - Last Post by FTDI Community
Hello,

Perhaps due to unaligned read/write.

An aligned write is a write on the FIFO interface with all byte enables selected, i.e. on a 16-bit interface, an aligned write is 16-bits wide and on a 32-bit interface, an aligned write is 32-bits wide.
 
An unaligned write is a write on the FIFO interface that is not as wide as the interface, i.e. on a 16-bit interface, an unaligned write is a single byte write and on a 32-bit interface, an unaligned write is 1, 2, or 3 bytes.
 
An aligned read is a read from the FIFO interface when the slave asserts all byte enables. On a 16-bit interface, an aligned read is 16-bits wide and on a 32-bit interface, an aligned read is 32-bits wide
 
An unaligned read is a read from the FIFO interface that is not as wide as the interface, i.e. on a 16-bit interface, an unaligned read is a single byte read and on a 32-bit interface, an unaligned read is 1, 2, or 3 bytes. An unaligned read from the slave always signals that it is a short packet

Further details can be found in AN_421 - https://www.ftdichip.com/Support/Documents/AppNotes/AN_412_FT600_FT601%20USB%20Bridge%20chips%20Integration.pdf

Regards,
FTDI Community

 6 
 on: October 21, 2019, 01:27:05 PM 
Started by donsiuch - Last Post by donsiuch
Hello! I recently purchased the FTDI C232HM-DDHSL-0 USB cable for use with SPI devices; my goal is to read the memory from an SPI memory chip. However, I am having issues getting the libMPSSE library & 2xx drivers to send signals to a connected memory chip. I hooked the leads of the C232 up to a Saleae logic analyzer and saw that no signals were being output! Following I give a description of my problem. I am new to this, so I will do the best I can to explain :)

I am using a Debian x86_64 machine. The MPSSE SPI download only had the i386 version of the library, so I downloaded the MPSSE SPI source and built the x86_64 bit version. There were no build errors or warnings. I then copied the x86_64 bit libftd2xx.so and .a, libMPSSE.so and .a to /usr/local/lib.

I plugged the cable in, then removed the following kernel modules:

  • ftdi_sio  <-- Readme says to take take out
  • usbserial  <-- Readme says to take out
  • usb_wann  <-- Needed to remove to take out usbserial
  • qcserial  <-- Needed to remove to take out usbserial

I connected 6x cables to the 8 pin memory chip (https://www.macronix.com/Lists/Datasheet/Attachments/7370/MX25L6406E,%203V,%2064Mb,%20v1.9.pdf):

  • VCC <--> red lead
  • Ground <--> black lead
  • Chip select <--> brown lead
  • Data in <--> green
  • serial clock <--> orange
  • Data out <--> yellow

I did not connect hold and write protect pins on the memory chip. Recall my goal is to read the memory out of the chip, and the waveform for the read did not show those pins were necessary.

I am using this simple program:
 
Code: [Select]
  /* Standard C libraries */
    #include<stdio.h>
    #include<stdlib.h>
    #include<string.h>
   
    #include "ftd2xx.h"
    #include "libMPSSE_spi.h"
   
    FT_HANDLE ftHandle;
   
    uint8 tx_buffer[4096] = {0};
    uint8 rx_buffer[4096] = {0};
   
    int main()
    {
        uint8 i = 0;
        int sizeToTransfer = 0;
        int sizeTransfered = 0;
    FT_STATUS status = FT_OK;
    FT_DEVICE_LIST_INFO_NODE devList = {0};
    ChannelConfig channelConf = {0};
   
    channelConf.ClockRate = 30000000; // 30Mhz
    channelConf.LatencyTimer = 75;
    channelConf.configOptions = SPI_CONFIG_OPTION_MODE0 | SPI_CONFIG_OPTION_CS_DBUS3 | SPI_CONFIG_OPTION_CS_ACTIVELOW;
    channelConf.Pin = 0x00000000;/*FinalVal-FinalDir-InitVal-InitDir (for dir 0=in, 1=out)*/
   
       
        //
        // Open the channel and dump some information
        //
        status = SPI_GetChannelInfo(0,&devList);
        if (status != FT_OK)
        {
            printf("SPI_GetChannelInfo failed, status = %d\n", status);
            return -1;
        }
        printf("Flags=0x%x\n",devList.Flags);
        printf("Type=0x%x\n",devList.Type);
        printf("ID=0x%x\n",devList.ID);
        printf("LocId=0x%x\n",devList.LocId);
        printf("SerialNumber=%s\n",devList.SerialNumber); // TODO: Why blank?
        printf("Description=%s\n",devList.Description);
        printf("ftHandle=0x%p\n",devList.ftHandle);/*is 0 unless open*/
   
   
        //
        // Open channel 0
        //
        status = SPI_OpenChannel(0,&ftHandle);
        if (status != FT_OK)
        {
            printf("SPI_OpenChannel failed, status = %d\n", status);
            return -1;
        }
   
        //
        // Initialize the channel: See configuration structure at top of main()
        //
        status = SPI_InitChannel(ftHandle,&channelConf);
        if (status != FT_OK)
        {
            printf("SPI_InitChannel failed, status = %d\n", status);
            return -1;
        }
   
        //
        // Send the read command (0x03), and read what we get in our receive buffer
        //
        sizeToTransfer=8;
    sizeTransfered=0;
    tx_buffer[0] = 0x03;
    status = SPI_ReadWrite(ftHandle, rx_buffer, tx_buffer, sizeToTransfer, &sizeTransfered,
                SPI_TRANSFER_OPTIONS_SIZE_IN_BYTES|SPI_TRANSFER_OPTIONS_CHIPSELECT_DISABLE|SPI_TRANSFER_OPTIONS_CHIPSELECT_ENABLE);
    if (status != FT_OK)
    {
    printf("SPI_ReadWrite failed, status = %d\n", status);
    return -1;
    }
   
        //
        // Dump the receive buffer to see if we got anything.
        //
    printf("Size transfered = %d\n", sizeTransfered);
    i = 0;
    while (i < sizeTransfered)
    {
    printf("%02x",rx_buffer[i]);
    i++;
    }
        printf("\n");
   
        //
        // Cleanup
        //
        status = SPI_CloseChannel(ftHandle);
        if (status != FT_OK)
        {  
            printf("SPI_CloseChannel failed, ret = %d\n", status);
        }
   
    return 0;
    }


To make and run the program:
Code: [Select]
    To compile: gcc read_memory.c -lMPSSE -ldl
    To run: sudo ./a.out

My output is:
Code: [Select]
   
// The driver can at least detect the cable.
Flags=0x2
Type=0x8
ID=0x4036001
LocId=0x204
SerialNumber=
Description=USB <-> Serial
ftHandle=0x(nil)
Size transfered = 8
   
// This output is displayed with I keep the memory chip connected or disconnect it. I believe the following buffer is just junk.
ff037fffffffffff

Whether I keep the memory chip connected or disconnected I get the same junk in the receive buffer. I see no LEDs light up on the cable or anything to indicate it is "working." I have tried SPI_Write() and SPI_Read() and get similar behavior. I tested on an Ubuntu VM (running on Windows host) and saw the exact same behavior.

Any help with this matter is greatly appreciated! Thanks

 7 
 on: October 21, 2019, 11:42:52 AM 
Started by Yunuce - Last Post by Yunuce
Hello;

I designed a PCB with FT905L MCU and when board connect to computer via USB, it is not recognized. How to fix this problem?


Quote
Device USB\VID_0000&PID_0002\5&3305c25d&0&1 was configured.
Details:
   Driver Name: usb.inf
   Class Guid: {36fc9e60-c465-11cf-8056-444553540000}
   Driver Date: 06/21/2006
   Driver Version: 10.0.17763.1
   Driver Provider: Microsoft
   Driver Section: BADDEVICE.Dev.NT
   Driver Rank: 0xFF0000
   Matching Device Id: USB\DEVICE_DESCRIPTOR_FAILURE
   Outranked Drivers: usb.inf:USB\DEVICE_DESCRIPTOR_FAILURE:00FF2000
   Device Updated: false
   Parent Device: USB\ROOT_HUB30\4&31305c27&0&0
Device USB\VID_0000&PID_0002\5&3305c25d&0&1 had a problem starting.
Details:
   Driver Name: usb.inf
   Class Guid: {36fc9e60-c465-11cf-8056-444553540000}
   Service:
   Lower Filters:
   Upper Filters:
   Problem: 0x2B
   Problem Status: 0x0
 

 8 
 on: October 20, 2019, 01:15:47 PM 
Started by atom1477 - Last Post by atom1477
But this not answers my question.
Could You clarify that 32-bit wide IO is possible or not in this mode?

 9 
 on: October 15, 2019, 02:27:59 PM 
Started by piezontm - Last Post by piezontm
I was wondering if there were any improvements or other things I can try?

 10 
 on: October 15, 2019, 11:01:44 AM 
Started by dsl400 - Last Post by FTDI Community
Hello,

Unfortunately it is not possible to access the EERPOM from the UART side of the IC.

Best Regards,
FTDI Community

Pages: [1] 2 3 ... 10