I get a "FT_INVALID_PARAMETER" error when calling the FT_EEPROM_Read function call from ftd2xx.dll, using Labview.

[ErikKlingenstierna]

Hi!

What am doing wrong?

I get a "FT_INVALID_PARAMETER" (6) error when calling the "FT_EEPROM_Read" function call from ftd2xx.dll, using Labview.

The Labview functions provided at

"http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/LabVIEW.htm"

do not include the “FT_EEPROM_Read” or the ” FT_EEPROM_Program” call.

I am running a 64-bit Windows 7 system.

Using Labview 2014 32-Bit

The ftd2xx.dll I am calling is:

File version 3.2.7.0

Product version 2,8,23,1

The chip I what to call is a FT231XQ (deviceType=9)

From the “D2XX Programmer's Guide Version 1.3” I can read:

FT_HANDLE DWORD

FT_STATUS (DWORD)

{

FT_OK = 0

FT_INVALID_HANDLE = 1

FT_DEVICE_NOT_FOUND = 2

FT_DEVICE_NOT_OPENED = 3

FT_IO_ERROR = 4

FT_INSUFFICIENT_RESOURCES = 5

FT_INVALID_PARAMETER =6

FT_INVALID_BAUD_RATE = 7

FT_DEVICE_NOT_OPENED_FOR_ERASE = 8

FT_DEVICE_NOT_OPENED_FOR_WRITE = 9

FT_FAILED_TO_WRITE_DEVICE = 10

FT_EEPROM_READ_FAILED = 11

FT_EEPROM_WRITE_FAILED = 12

FT_EEPROM_ERASE_FAILED = 13

FT_EEPROM_NOT_PRESENT = 14

FT_EEPROM_NOT_PROGRAMMED = 15

FT_INVALID_ARGS = 16

FT_NOT_SUPPORTED = 17

FT_OTHER_ERROR = 18

} 

FT_DEVICE (DWORD)

{

FT_DEVICE_232BM = 0

FT_DEVICE_232AM = 1

FT_DEVICE_100AX = 2

FT_DEVICE_UNKNOWN = 3

FT_DEVICE_2232C = 4

FT_DEVICE_232R = 5

FT_DEVICE_2232H = 6

FT_DEVICE_4232H = 7

FT_DEVICE_232H = 8

FT_DEVICE_X_SERIES = 9

} 

EEPROM_HEADER STRUCTURE (See FT_EEPROM_Read and FT_EEPROM_Program)

typedef struct ft_eeprom_header {

FT_DEVICE deviceType;

WORD VendorId;

WORD ProductId;

UCHAR SerNumEnable;

WORD MaxPower;

UCHAR SelfPowered;

UCHAR RemoteWakeup;

UCHAR PullDownEnable;

} FT_EEPROM_HEADER, *PFT_EEPROM_HEADER;

FT X Series EEPROM structure for use with FT_EEPROM_Read and FT_EEPROM_Program

typedef struct ft_eeprom_x_series {

FT_EEPROM_HEADER common;

UCHAR ACSlowSlew;

UCHAR ACSchmittInput;

UCHAR ACDriveCurrent;

UCHAR ADSlowSlew;

UCHAR ADSchmittInput;

UCHAR ADDriveCurrent;

UCHAR Cbus0;

UCHAR Cbus1;

UCHAR Cbus2;

UCHAR Cbus3;

UCHAR Cbus4;

UCHAR Cbus5;

UCHAR Cbus6;

UCHAR InvertTXD;

UCHAR InvertRXD;

UCHAR InvertRTS;

UCHAR InvertCTS;

UCHAR InvertDTR;

UCHAR InvertDSR;

UCHAR InvertDCD;

UCHAR InvertRI;

UCHAR BCDEnable;

UCHAR BCDForceCbusPWREN;

UCHAR BCDDisableSleep;

WORD I2CSlaveAddress;

DWORD I2CDeviceId;

UCHAR I2CDisableSchmitt;

UCHAR FT1248Cpol;

UCHAR FT1248Lsb;

UCHAR FT1248FlowControl;

UCHAR RS485EchoSuppress;

UCHAR PowerSaveEnable;

UCHAR DriverType;

} FT_EEPROM_X_SERIES, *PFT_EEPROM_X_SERIES;

I think this should result in the following cluster to send to the dll

The vi I use to call the look like this:

 

“deviceType” is set to “9”

“Handle” is set to the value returned from the Open function

“eepromDataSize” is set to 0-23000

Why do I get a “FT_INVALID_PARAMETER”?

Hope you can help me out with this.

Best regards

[aevans2]

Hi Erik,

Did you make this code yourself or is it from the supplier?

Also, some of those chips have a known problem where the virtual COM Port is set to inactive, are you able to see it in device manager?

Alex

[ErikKlingenstierna]

Hi Alex,

The "Open" and "Close" function in "FT_EEPROM_Read.zip" are copies of the code from the supplier.

The "FT_EEPROM_ReadEx.vi" I made myself. The supplier does not include a “FT_EEPROM_Read” vi.

I must apologize for the name "FT_EEPROM_ReadEx.vi". The function makes the dll call "FT_EEPROM_Read" 

I can see the COM Port in the device manager. I can also send and receive data using the COM Port.

Best regards

Erik

[rolfk]

Two comments/questions:

1) What do you pass in for the eepromDataSize value??

2) The string buffers you allocate may be a little small. The example in the programming manual allocates for all of them 64 bytes but is unspecific about how much is really enough, only stating that the example is using sizes that are more than adequate.

1) is most likely your problem. The function expects here a size in bytes for the structure you pass in. I'll leave the exercise to calculate that to you. 

2) if wrong would cause a 1097 error or crash

[ErikKlingenstierna]

Hi Rolf.

Thanks for the tip to concentrate on "eepromDataSize"

When counting the bytes in the cluster I get 49. 

The "eepromDataSize" has to be set to 56 to not get a "FT_INVALID_PARAMETER". 

It looks like the size of the parameters as specified in the "ft_eeprom_x_series"-struct do not match what the dll actually require

Although no error is accrues, the data from the "FT_EEPROM_Read" call looks like it has been shifted as if some [U8] parameters should be [U16]

That would explain the 49 - 56 difference. 

Is the "D2XX Programmer's Guide Version 1.3" wrong?

Any ideas on how to get the right type for every parameter?

Best regards

Erik

[rolfk · Accepted solution]

You forget structure element alignment. A C compiler has an alignement which defines that an element in a cluster needs to be aligned to the smaller of either its own size and the alignment value. This alignement value in Visual C is default set to 8 byte but can be changed with compiler options as well as with #pragma pack() directives directly in the C source code.

LabVIEW on the x86 platform uses always an alignment of 1 byte which means it packs its data maximally. In order for a LabVIEW cluster to match an aligned structure you have to add filler bytes, words and longs into the cluster. A quick glance shows that your structure would then indeed result in 55 bytes. The additional byte is appended at the end in order to make the structure aligned for the DWORD element in the beginning when the structure would be used as an array element.

EEPROM_HEADER STRUCTURE (See FT_EEPROM_Read and FT_EEPROM_Program)
typedef struct ft_eeprom_header {
FT_DEVICE deviceType;          4 bytes

WORD VendorId;                 2
WORD ProductId;                2

UCHAR SerNumEnable;            1
UCHAR filler1;                 1
WORD MaxPower;                 2

UCHAR SelfPowered;             1
UCHAR RemoteWakeup;            1
UCHAR PullDownEnable;          1
UCHAR filler2;                 1
} FT_EEPROM_HEADER, *PFT_EEPROM_HEADER;
Total                         16               
FT X Series EEPROM structure for use with FT_EEPROM_Read and FT_EEPROM_Program
typedef struct ft_eeprom_x_series {
FT_EEPROM_HEADER common;      16
UCHAR ACSlowSlew;              1
UCHAR ACSchmittInput;          1
UCHAR ACDriveCurrent;          1
UCHAR ADSlowSlew;              1

UCHAR ADSchmittInput;          1
UCHAR ADDriveCurrent;          1
UCHAR Cbus0;                   1
UCHAR Cbus1;                   1

UCHAR Cbus2;                   1
UCHAR Cbus3;                   1
UCHAR Cbus4;                   1
UCHAR Cbus5;                   1

UCHAR Cbus6;                   1
UCHAR InvertTXD;               1
UCHAR InvertRXD;               1
UCHAR InvertRTS;               1

UCHAR InvertCTS;               1
UCHAR InvertDTR;               1
UCHAR InvertDSR;               1
UCHAR InvertDCD;               1

UCHAR InvertRI;                1
UCHAR BCDEnable;               1
UCHAR BCDForceCbusPWREN;       1
UCHAR BCDDisableSleep;         1

WORD I2CSlaveAddress;          2
WORD filler3;                  2

DWORD I2CDeviceId;             4

UCHAR I2CDisableSchmitt;       1
UCHAR FT1248Cpol;              1
UCHAR FT1248Lsb;               1
UCHAR FT1248FlowControl;       1

UCHAR RS485EchoSuppress;       1
UCHAR PowerSaveEnable;         1
UCHAR DriverType;              1
UCHAR filler4;                 1
} FT_EEPROM_X_SERIES, *PFT_EEPROM_X_SERIES;

[ErikKlingenstierna]

Thank you Ralf for this excellent description and solution of my problem!

After putting filler-data in the cluster-positions you suggested the functions works fine.

My question was: What am I doing wrong?

First:

- I did not adjust for the "C compiler alignment". That is, adding the 4 fillers to the cluster.

Second:

- I did not calculate the "eepromDataSize" right, it should be 56.

The attached files include vi's:

"FT_EEPROM_Read”

”FT_EEPROM_Program"

and the cluster:

FT_EEPROM_X_SERIES.ctl

necessary to read and program a FT231XQ (deviceType=9) chip.

Thanks again for your help.

Erik.

[tcie]

hi I did modify your memory map to be more user readable, also you have a bug in I2CDeviceId: it should be 4 byte not 2 byte long

[ForestCamlin2]

Thanks for the post. It relay saved couple of nerves.

@ErikKlingenstierna please note that in your definition of FT_EEPROM_X_SERIES.ctl there is missing "Cbus2" field. After adding this field, first following filler (Filler 3) must be reduced by 1 byte to keep the structure size. 

@tcie can you save you "FT_EEPROM_X_SERIES with rings.ctl" in NI2019 version?