timothyjohncarney / libmpsse Goto Github PK

What steps will reproduce the problem?

1. Using an FTDI C232HM-DDHSL-0, USB to MPSSE cable connecting Linux server to 
I2C/SMBus/PMBus power supply
2. Repeating many times, command the power supply to provide a data value
3. Read a known 16 bit data value from the power supply
4. Observe the I2C traffic with a scope

What is the expected output? What do you see instead?

We expect 0xC6 0x00, and get it about 99% of the time. About 1% of the time the 
we see 0xC6 0x02 or 0xC6 0x08. And extra bit, always only one extra bit, is set 
in the byte that should be 0x00. When we look at the data with the scope, the 
bad values appear to be good clean representations of 0x00.

What version of the product are you using? On what operating system?

libmpsse 1.3, using the C interface, CentOS 6.4. 

Please provide any additional information below.

There're obviously many ways this could be a system problem having nothing to 
do with libmpsse. But I wonder if anyone has seen something similar.

thanks, Michael

What steps will reproduce the problem?
1. incorrect compiled libmpsse.(a/so) if make is run multiple times, 
2.
3.

What is the expected output? What do you see instead?

same result each time one runs make with C library containing C version and 
swig library containing swig version.

Instead the C library contains the swig version of functions if make is run 
twice.

What version of the product are you using? On what operating system?

SVN 202, Linux

Please provide any additional information below.

Patch attached.

What steps will reproduce the problem?
1. open the terminal
2. super user
3. extract the file
4. go into the src folder
5. run ./configure in the terminal

What is the expected output? 
Checking for malloc… no
Configure: error: “missing standard functions”

What do you see instead?
Checking for malloc… yes

What version of the product are you using? On what operating system?
libmpsse-1.2-1, fedora 16

Please provide any additional information below.
I had installed the glibc and also the gcc.

I am patronized libmpsse!!

The current version(1.3) available only one device.
I've created a patch that supports multiple deive(up to four).
As Chip Select, CS, GPIO0, GPIO1, GPIO2 can be use.

usage:
  c:
    mpsse_= OpenIndexWithCS(vid, pid, mode, freq, endianess, interface, description, serial, index, {CS|GPIO0|GPIO1|GPIO2});
　python
    mpsse = MPSSE()
    mpsse = mpsse.Open(vid, pid, mode, cs={CS|GPIO0|GPIO1|GPIO2})

My environment
    BeagleBone Black / Debian(wheezy)
    Raspberry Pi / Raspbian(2013-09-25-wheezy)

If it is good, Please relish.
Thank you.

The FT232H supports open-drain outputs to become fully I2C compatible. This 
prevents bus conflicts when a slave device tries to acknowledge.

What steps will reproduce the problem?
1. Open device in SPI or I2C mode
2. call SetDirection method
3. Exception is thrown

What is the expected output? What do you see instead?
I was unable to set specific pin to input mode when in MPSSE mode. I recommend 
attached patch

Additional information
mpsse.i.patch described under issues had to be applied in advance

What version of the product are you using? On what operating system?
libmpsse-1.3 on linux ubuntu

What steps will reproduce the problem?
1. With lattop, install MinGW with msys shell in C:\MinGW
2. copy "libftdi1-1.0_devkit_mingw32_17Feb2013" lib\ and bin\ and include\ 
folder into C:\MinGW
3. In msys shell run mingw-get install mingw32-automake mingw32-autotools 
mingw32-autoconf
4. copy "libmpsse-1.3" to c:\libmpsse-1.3
5. In msys shell "cd c:\libmpsse-1.3\src"
6. In msys shell "autoconf && ./configure --disable-python && make"
7. In msys shell "make install"


What is the expected output? What do you see instead?
I expect libmpsse installed.  So I can run "make example-code".  But it shows 
"install -D -m644 libmpsse.so //usr/local/lib/libmpsse.so; install: accessing 
'//usr/local/lib/libmpsse.so': No such host or network path make: [install] 
Error 1"

What version of the product are you using? On what operating system?
libftdi1-1.0_devkit_mingw32_17Feb2013
libmpsse-1.3
Windows8
MinGW with mingw32

Please provide any additional information below.

What steps will reproduce the problem?
1. Build and install libftdi1 to /home/cmorgan/local_install
2. Run configure in libmpsse with:
./configure --prefix=/home/cmorgan/local_install CFLAGS="-I 
/home/cmorgan/local_install/include -fPIC" LDFLAGS="-L 
/home/cmorgan/local_install/lib64"
3. Output is:

checking for GNU libc compatible malloc... yes
checking libftdi1/ftdi.h usability... yes
checking libftdi1/ftdi.h presence... no
configure: WARNING: libftdi1/ftdi.h: accepted by the compiler, rejected by the 
preprocessor!
configure: WARNING: libftdi1/ftdi.h: proceeding with the compiler's result
checking for libftdi1/ftdi.h... yes
checking for ftdi_init in -lftdi1... yes
checking /usr/include/python2.7/Python.h usability... yes
checking /usr/include/python2.7/Python.h presence... yes
checking for /usr/include/python2.7/Python.h... yes
configure: creating ./config.status
config.status: creating Makefile


I looked in config.log:

configure:3355: gcc -c -Wall -fPIC -fno-strict-aliasing -I 
/home/cmorgan/local_install
configure:3355: $? = 0
configure:3355: result: yes
configure:3355: checking libftdi1/ftdi.h presence
configure:3355: gcc -E  conftest.c
conftest.c:21:27: fatal error: libftdi1/ftdi.h: No such file or directory
 #include <libftdi1/ftdi.h>
                           ^
compilation terminated.

I have no idea why CFLAGS isn't being used in the compile check. Is there some 
way to specify the path to libftdi1 via a configure option?

What steps will reproduce the problem?
1. Open in I2C mode
2. Issue start condition (call Start() method)

I found a bug in Start() method.
See the attached patch file.

I try to communicate with the MCP3202 A/D converter. This converter from 
Microchip has an SPI interface and, according to the documentation, at the 
begginning of communication I've to send 4 bits to the A/D in order to select 
the input analog channel, set the bit-ordering mode, etc. After sending these 4 
bits, subsequential 13 clock cycles will output a null bit and the 12 bits of 
the converted value.

So, using the "write" function is not an option because as far as I know this 
function sends only a byte at a time, and I must write only 4 bits to the chip, 
not an entire byte. Is there any way to do so with libmpsse? or I've to modify 
it?

For the sake of reference, this A/D chip is part of a DLP-2232DAQ board. I've 
managed yet to communicate with the I/O ports included there thanks your great 
libmpsse, so thank you for your work!

FastTransfer is called with pointer to a non empty output buffer, and an input 
buffer, transfer size : 2 bytes.

Expecting a 2-byte SPI transaction, but only the start and stop condition (CS 
going down and then up) appear on a logic analyzer.
Function returns MPSSE_FAIL.

Code :

    uint8_t outbuf[2];
    uint8_t inbuf[2];
[...]
    outbuf[0] = READ_ACCESS | (address & 0x7F);
    outbuf[1] = 0x00;
    i = Start(mpsse);
    j = FastTransfer(mpsse, (char *)outbuf, (char *)inbuf, 2);
    k = Stop(mpsse);


Using libmpsse 1.3 with a FT2232H on a Linux ARM system (Pcduino).


An similar subroutine calling
    j = FastWrite(mpsse, (char *)outbuf, 2);
is working properly.

The attached patch fixes misc. issues in the Makefile that make easier the 
packaging of libmpsse.

This patch is for the libmpsse-1.2 release, and has been generate from the 
tarball.

To apply this patch:
$ tar xaf libmpsse-1.2.tar.gz
$ cd libmpsse-1.2
$ patch -p0 <libmpsse-1.2-fix-Makefile.patch


Yours,

What steps will reproduce the problem?
1. Any call to WritePins fails

What is the expected output? What do you see instead?
Get an MPSSE_FAIL for return value instead of MPSSE_OK

What version of the product are you using? On what operating system?
latest SVN version.

Please provide any additional information below.
I looked at this and found, much to my chagrin, that when I'd given you this 
function, I was only checking for ftdi_write_data to return 0.  The latest 
libftdi version doesn't do that.  It actually returns the number of bytes 
written, in which case the following:
if(ftdi_write_data(&mpsse->ftdi, &data, 1) == 0)

will always fail, even if there is a success.  It probably should read:
if(ftdi_write_data(&mpsse->ftdi, &data, 1) > 0)

I guess it could even read:
if(ftdi_write_data(&mpsse->ftdi, &data, 1) >= 0)

I would send a patch instead, but I made the change without creating a git 
repository.  Since it was a trivial change, it is no big deal.  I'm guessing 
not too many people use this function.  I don't know if, given some of the 
library additions, there is now a better, or different way to achieve what this 
achieved.

Thanks for taking a look.

What steps will reproduce the problem?
1. Using an SPI MCP4262, Send a read command through either python or c code... 
2. Try to read the value during the write cycle

For example:

from mpsse import *

spi = MPSSE(SPI0, 250000)
spi.Start()
spi.Write('\x5F\xFF')
spi.Stop()
spi.Read(2)

What is the expected output? What do you see instead?

No matter what combination of writes and reads you try, you cannot get the data 
sent
during the write cycle.  In this case, you should see \xFF\xE0 on a default 
chip.

What version of the product are you using? On what operating system?
libmpsse-1.1

Please provide any additional information below.
It is possibly a libftdi problem, since the interface doesn't seem to be 
exposed to access the read fifo from the FTDI chip.  Maybe adding in some 
access in libftdi or some direct USB access to that data.

The biggest problem is that most people are using "fake" SPI devices which 
support Write then Read.
The SPI protocol should support Reading the data while writing as it is part of 
the spec and the FTDI
chip does seem to support it.

What steps will reproduce the problem?
1. Use PC to install mingw with msys shell.
2. install libftdi1-1.0_devkit_mingw32_17Feb2013.zip
3. install libmpsse-1.3.
4. use C232HM USB 2.0 Hi-Speed to MPSSE cable.

What is the expected output? What do you see instead?
Should work.
After run spiflash.exe, shows "Failed to initialize MPSSE: device not found"

What version of the product are you using? On what operating system?
libmpsse-1.3 on windows8 mingw.

Please provide any additional information below.
Issue24 has the same issue.  But I don't know how to run as root in mingw msys 
shell.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Latest libftdi puts the ftdi.h file in libftdi/ftdi.h. Add a check for this in 
the configure script.

What steps will reproduce the problem?
1. read data using raw_read() or Read() or Transfer()

What is the expected output? What do you see instead?
Fast response.  Delayed response.

What version of the product are you using? On what operating system?
libmpsse 1.2 Mac OS X

Please provide any additional information below.

        /* Make sure the buffers are cleared after a read or subsequent reads may fail */
        ftdi_usb_purge_rx_buffer(&mpsse->ftdi);
        ftdi_usb_purge_tx_buffer(&mpsse->ftdi);
        ftdi_usb_purge_buffers(&mpsse->ftdi);

ftdi_usb_purge_buffers already clears both of the buffers by calling 
ftdi_usb_purge_rx_buffer and ftdi_usb_purge_tx_buffer.  In my use of libmpsse 
using SPI, a purge buffer command is not even needed at all.

What steps will reproduce the problem?
1. "./configure" fails

This problem is related to my previous response on another issue:
https://code.google.com/p/libmpsse/issues/detail?id=32#c2

For Mac OS X + MacPorts, it seems that there is an easier way to globally 
enable (custom) builds to use the "/opt/local" in the search path of compiler.

edit your environment settings (eg. "/etc/profile") and append:
export LDFLAGS="-L/opt/local/lib"
export CFLAGS="-I/opt/local/include"
export CPPFLAGS="-I/opt/local/include"

Remember to (re)open a new terminal for the changes to take effect and then it 
works just fine to execute the default configure:
------------------------------------------
$ ./configure
------------------------------------------

Although it actually might make sense to update the install path for libmpsse 
accordingly:
------------------------------------------
$ ./configure --prefix=/opt/local/
------------------------------------------

Next, to be able to run "make install" in OS X, the "-D" option should not 
present in the Makefile. So replace all "install -D ..." to "install ..." and 
you can install it without a problem.
------------------------------------------
$ sudo make install
------------------------------------------
I'm not sure if the "-D" option is necessary for other unix systems like 
linux/bsd, otherwise it might be a suggestion to just remove this directive 
from the "Makefile.in" in the current repository.

Last issue I ran into is compiling the examples afterwards.
The Makefile in the "libmpsse/src/examples" directory currently does not work 
with globally defined compile and linker flags.
------------------------------------------
$ cd libmpsse/src/examples
$ make
------------------------------------------
cc -I/opt/local/include spiflash.c -o spiflash -lmpsse
ld: library not found for -lmpsse
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [spiflash] Error 1
------------------------------------------

However, when we patch the first line of "libmpsse/src/examples/Makefile":
"LDFLAGS=-lmpsse" -> "LDFLAGS+=-lmpsse"
Then it works just fine!
------------------------------------------
$ cd libmpsse/src/examples
$ make
------------------------------------------
cc -I/opt/local/include spiflash.c -o spiflash -L/opt/local/lib -lmpsse
cc -I/opt/local/include spiflashfast.c -o spiflashfast -L/opt/local/lib -lmpsse
cc -I/opt/local/include i2ceeprom.c -o i2ceeprom -L/opt/local/lib -lmpsse
cc -I/opt/local/include ds1305.c -o ds1305 -L/opt/local/lib -lmpsse
cc -I/opt/local/include gpio.c -o gpio -L/opt/local/lib -lmpsse
cc -I/opt/local/include bitbang.c -o bitbang -L/opt/local/lib -lmpsse
------------------------------------------
Also this patch might be useful to actually embed into the repository.

THIRY_MHZ must be THIRTY_MHZ
TEN_MHZ != 1000000 it must be TEN_MHZ = 10000000

What steps will reproduce the problem?
Using the following python:
from mpsse import *
a = MPSSE()
c = MPSSE()
a.Open(0x403, 0x6011, SPI0, ONE_MHZ, MSB, IFACE_A)
c.Open(0x403, 0x6011, GPIO, ONE_MHZ, MSB, IFACE_C)

c.Stop()
c.PinHigh(7)

What is the expected output? 
On my board, the GPIO of port C (pin 7 in this case) is hooked up to a chip 
select.  So I need to be able
to toggle this to access the SPI on port A (which will eventually be JTAG, but 
it starts of as SPI).  There is
an LED attached which goes on and off when you change the pin high and low.

What do you see instead? Nothing happens.


What version of the product are you using? Latest SVN (doesn't have the patch 
to clear errors when
you start.)

what operating system? Ubuntu 12.10 LTS


Please provide any additional information below.

I could be misusing the GPIO functionality, but it didn't seem to work.  I have 
a patch, which I attached, which adds "BITBANG".  I added this because I was 
afraid I was missing something when I looked at what GPIO was doing and did not 
want to change GPIO if I misunderstood it.  But it appears that if you use 
GPIO, it doesn't really do anything.  I traced why at one point, created the 
patch, and promptly forgot why.  At any rate, the BITBANG functionality seems 
to do what I needed to do (or at least make PinHigh/PinLow function as I 
expected they would).

What steps will reproduce the problem?
Set MPSSE to Ack following each read byte.
Perform an I2C Read followed by a Stop.  The number of bytes read doesn't 
matter.

What is the expected output? What do you see instead?
Using a logic analyzer, I can see that where the stop is issued, the SCL line 
goes high but the SDA line always stays low.  The next I2C operation fails 
because a valid start condition can't be generated.

Calling SendNacks and issuing a dummy read is incorrect if you are trying to 
read from a device that has a FIFO buffer or auto-incrementing support.

What version of the product are you using? On what operating system?
LibMPSSE v1.3 along with ftdi v1.0 on OSX 10.8.5

Please provide any additional information below.
I've tried forcing the SDA line high with a variety of set_bits or PinHigh 
calls without success.  I've tried using the FlushAfterRead call as well.  I'm 
trying to talk to an Invensense MPU9150 digital motion processor.

Hi,

I see in your code a lot of malloc/memcopy/free calls. All this stuff heavily 
impact the performances (latency) of the code (which are very important on my 
use case) so I wrote a couple of additional files (fast_spi_mpsse.h/c) in order 
to speed-up the SPI (and only SPI) transfer by removing all but one mandatory 
memcopy.
The new functions are basically the same as the ones found in your code except 
that the rx and tx buffer (and their size) need to be provided by the user.

I also did a really minor change on the MPSSE function (interface is now a 
parameter).

I attach the patch file including all the above changes, feel free to to use 
that code by your convenience.

Cheers,
Paolo.

I'm trying to build libmpsse trunk (r202) out-of-source. So something like:


cd somedirectory
../../../libmpsse/src/configure --prefix=/local_install_directory 
CFLAGS="-I/myotherrootfs" LDFLAGS="-L/myotherrootfs/lib64"

Configure succeeds and generates a makefile but the file names are all relative 
to the original source directory.

This looks to come directly from Makefile.in (I'm not super familiar with 
autotools at this point):

mpsse.o: support.o
    $(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c mpsse.c

I've started to modify the Makefile.in to use ${srcdir) etc but I'm wondering 
if you would be opposed to switching to cmake. Libftdi uses it for their build 
system and I suspect it would make it much easier to handle things like this. 
It would also make it easier to detect libftdi, there is a helpful cmake script 
that libftdi installs that will retrieve the libraries and include paths.

I could provide the CMakeLists.txt file if that would be helpful as I need to 
integrate this into our build system and we try hard to perform out-of-source 
builds.

[email protected] if you want to get ahold of me.

What steps will reproduce the problem?
1. run configure
2. run make

What is the expected output? What do you see instead?
A built lib

What version of the product are you using? On what operating system?
Linux version 2.6.38-8-generic (buildd@allspice) (gcc version 4.5.2 
(Ubuntu/Linaro 4.5.2-8ubuntu3) ) #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

Please provide any additional information below.
Please see patch.

What steps will reproduce the problem?
1. There really aren't any steps here, it appears there isn't any way to set 
pin direction for bitbang mode or to set all pins at the same time.

Please provide any additional information below.

I was looking for a way to "bulk" set the pins of a particular interface in 
bitbang mode.  It appears that I can read and write them using PinHigh/PinLow 
individually.  This is certainly useful, but I wanted to be able to "set them 
all at once" for an application I am doing.  In this case, I have a sort of 
"JTAG finder" that can scan pins and "hunt" for JTAG.  In order for that to 
work though, I have to be able to change the pin direction as well as be able 
to set pins "all at once".  So I created a SetDirection and a WritePins 
function.

I don't know if you will find them generally useful or not, but I thought they 
could be.  Even without the WritePins functionality, I figured the SetDirection 
might be needed in BitBang mode.

It is a patch against the latest release, *NOT* the latest SVN.  Hope that 
doesn't create any issues.  At any rate, it does seem to work and my JTAG 
finder appears to do the job.

libmpsse really is one of the neatest libraries out there.  I guess that is 
because it is connected with some of the coolest/cheapest hardware I've seen in 
a while.  It can REALLY get your PC/laptop connected to a lot of hobby stuff.

What steps will reproduce the problem?
1. Try to call FastTransfer
2.
3.

What is the expected output? What do you see instead?

That the transfer gets carried out. But it always errors.

What version of the product are you using? On what operating system?

SVN #202. Linux.

Please provide any additional information below.

Patch attached.

In file included from fast.c:10:0:
mpsse.h:9:18: fatal error: ftdi.h: No such file or directory

Makefile.in seems to not be passing LIBFTDI1 define when compiling fast.c. 
Patch attached.

Hello
I installed all the needed Packages including libftdi1
but it still comes up with a fault 
i extractet the header files from the FT Folder to setup folder but no luck 
where i should put the files?

Here a part from the Log

checking for /usr/include/python2.7/Python.h... yes
configure: creating ./config.status
config.status: creating Makefile
gcc -Wall -fPIC -fno-strict-aliasing -g -O2 -lftdi1  -c fast.c
In file included from fast.c:10:0:
mpsse.h:9:18: fatal error: ftdi.h: No such file or directory
 #include <ftdi.h>
                  ^
compilation terminated.
make: *** [fast.o] Error 1
System Debian x64

Regards,

Al

What steps will reproduce the problem?
1. Build code against libftdi1 installed to non-system directory
2. Call make with the path to the include/ that contains libftdi1/
2. Compilation will fail at fast.o
make CFLAGS="-I/home/cmorgan/local_install/include -fPIC"
...
gcc -I/home/cmorgan/local_install/include -fPIC -lftdi1 -L 
/home/cmorgan/local_install/lib64 -c fast.c
In file included from fast.c:10:0:
mpsse.h:9:18: fatal error: ftdi.h: No such file or directory
 #include <ftdi.h>
                  ^
compilation terminated.
make: *** [fast.o] Error 1

3. Modify the make line to include the libftdi1 directory like:
 make CFLAGS="-I/home/cmorgan/local_install/include/libftdi1 -fPIC"

4. Now other files will fail to compile like:

n/local_install/lib64 -DSWIGPYTHON -DLIBFTDI1=1 -c support.c
support.c:11:27: fatal error: libftdi1/ftdi.h: No such file or directory
 #include <libftdi1/ftdi.h>
                           ^
compilation terminated.

5.Go back to the original make line to finish the compile:

make CFLAGS="-I/home/cmorgan/local_install/include -fPIC"


The issue appears to be this in the makefile:

mpsse.o: support.o
        $(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c mpsse.c

fast.o: support.o
        $(CC) $(CFLAGS) $(LDFLAGS) -c fast.c <------------ Lack of LIBFTDI1 define

support.o:
    $(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c support.c



When fast.o is being built fast.c is compiled which eventually includes mpsse.h 
which looks for the 0.x series libftdi headers like <ftdi.h> instead of 
<libftdi1/ftdi.h>.

Modifying Makefile.in to go from:

fast.o: support.o
        $(CC) $(CFLAGS) $(LDFLAGS) -c fast.c


to: 

fast.o: support.o
        $(CC) $(CFLAGS) $(LDFLAGS) -DLIBFTDI1=$(LIBFTDI1) -c fast.c

Fixes the issue here.

I can submit a patch or test etc, just email me, [email protected]

What steps will reproduce the problem?
1. Run the attached code changing the slave address to whatever slave address 
your I2C device uses and to whatever register you can read and write to
2. I included some code that uses the ftdi command that would clock in the 
data, which does work. Just comment that out and uncomment the part right after 
//Read 1 of the registers.

What is the expected output? What do you see instead?
The expected outcome is whatever you wrote to the address. I just get a seg 
fault. When trying to print the pointer to the data, I just get the size that I 
inputted to the Read command


What version of the product are you using? On what operating system?
Using libmpsse-1.3 on Fedora 19


Please provide any additional information below.

What steps will reproduce the problem?
1. Tested with SFP optical transceiver, although it might be reproducible using 
EEPROMs. Adapt the i2ceeprom example code to read a block of data from an I2C 
peripheral device.
2. Run the example with the peripheral device. Verify it reads meaningful data.
3. Then, rerun the example without resetting the peripheral.

What is the expected output? What do you see instead?
Depending on the data contents being read, in some cases the peripheral will 
fail the second read, usually returning all 0xFF bytes.

What version of the product are you using? On what operating system?
SVN version as of 02/27/2012, OS is CentOS 6.2 with libftdi1 and libusb1.

Please provide any additional information below.
Scope shows that the error is caused by the peripheral device's failure to 
release control of the SDA line after we are finished reading from it. When the 
problem occurs, the SDA line remains pulled low, as is the peripheral is trying 
to clock out more data for the master. That is indeed the case. The problem is 
caused by the build_block_buffer() function in support.c module, which ends the 
final byte read from I2C with ACK instead of NACK. See the recommendation at 
http://www.nxp.com/documents/user_manual/UM10204.pdf chapter 3.1.6: "...When 
SDA remains HIGH during this ninth clock pulse, this is defined as the Not 
Acknowledge signal. The master can then generate either a STOP condition to 
abort the transfer, or a repeated START condition to start a new transfer."
Patching the support.c to include something like this at line 169:
//buf[i++] = mpsse->tack;
buf[i++] = (j < num_blocks - 1) ? 0x00 : 0xFF; //NACK the last byte
resolves the problem, at least in my case. The STOP sequence is then properly 
executed and the program can be successfully restarted many times without 
resetting the peripheral.

USB VID and PID values are not set when opening a device.

What steps will reproduce the problem?
1. Establish an i2c context
2. PinHigh(ctx, GPIOL2)
3.

What is the expected output? What do you see instead?

Expected output is that GPIOL2 is in high state but no other changes to pin 
state.

But actual effect is that a I2C start condition is unexpectedly being sent, 
causing problems for following I2C transaction.

What version of the product are you using? On what operating system?

SVN Revision 202. Linux.

Please provide any additional information below.

Patch attached.

What steps will reproduce the problem?
1. Set MPSSE.SPI.Open(SPI1, ***, MSB) or MPSSE.SPI.Open(SPI3, ***, MSB)
2. Attach scope to SCLK, MOSI and CS lines
3. Write one byte

What is the expected output? What do you see instead?

8 clock cycles are expected on SCLK, but another clock edge appears at the end 
of the transmission: this edge appears BEFORE CS goes high, thus it is received 
by any guest device present on the SPI bus, causing it to shift its internal 
register once more.

In SPI mode 1 the clock should remain low after the last (8th) falling edge, 
while in SPI mode 3 the clock should remain high after the 8th rising edge.
Modes 0 and 2 operate correctly.


What version of the product are you using? On what operating system?

Using r122 from svn (same problem happens with release 1.2-1), host device is a 
C232HM cable equipped with a FTDI232H IC.
OS is gentoo x86-64, libftdi 0.20


Please provide any additional information below.

I was trying to communicate with an AD5293, that supports only SPI mode 1. Word 
size is 2 Bytes.
The device was ignoring all the commands.
After analyzing the data coming out of MISO, I realized that the read-back word 
was the same I'd input, only shifted one position.

Using the scope I was able to verify that another clock edge indeed appears on 
SCLK before the chip select is removed (a rising edge, in this case), the clock 
then proceeds to remain high until the end of the transmission (even if it's 
supposed to idle low in mode 1).

SPI mode 1 devices are supposed to clock out the MSB of their internal register 
on the rising edge of SCLK, therefore the additional clock edge effectively 
shifts the guest device internal register, making the command invalid.

Also, some devices (like the AD5293) have an internal counter attached to SCLK 
and, if the count is not an exact multiple of the word size, they will ignore 
the received data altogether (which is what happens in my case, since the 
device counts 17 clock cycles).

Digging into mpsse.c, I stumbled upon the comment on line 381, which at first 
sight seemed to be the source of my problems.
I tried to replace {mpsse->pstop |= SK} with {mpsse->pstop &= ~SK}, hoping that 
would solve the issue, but this change has no effect whatsoever: the clock 
keeps going high at the end of the transmission.

I've verified that the opposite thing is happening in mode 3: in this case, the 
clock goes low before the chip select is removed, adding a 9th (falling) clock 
edge.
The behavior persists even if I change the pstop condition on mpsse.c:369.

What steps will reproduce the problem?
1. Download and build libmpsse R121 revision (using libusb-0.1.12 libftdi-0.20)
2. Build 'gpio.c' example
3. Run gpio example

What is the expected output? What do you see instead?
Example runs smoothly, except that it crashes with a segfault when 
MPSSE.GPIO.Close is called.

What version of the product are you using? On what operating system?
R121 on Linux Ubuntu 

 It's not really a problem, but I'm rather perplexed as to how to talk to specific I2C slaves. I only saw the i2ceeprom example, which somehow doesn't seem like what I need.

 I basically have an I2C slave on address 0x48 (it's an A->D converter, but that doesn't really matter). Later on I'll also add another I2C slave on the same line, so I really need to specify the proper addresses to talk to them.

 So how could I do something like:

#define ADS1015_REG_POINTER_CONFIG      (0x01) 
#define ADS1015_REG_POINTER_CONVERT     (0x00)

 int Address=0x48;
 ioctl(i2cFile, I2C_SLAVE, Address);
 i2c_smbus_write_word_data(i2cFile,ADS1015_REG_POINTER_CONFIG,0x1122);
 i2c_smbus_read_word_data(i2cFile,ADS1015_REG_POINTER_CONVERT);

 with libmpsse?

I have multiple devices identifying with the standard FTDI pid and vid, since 
our organisation does not have an own vendor id.

The devices (different versions of a PCB) identify themselves with different 
product descriptions, carrying a board revision. Therefore, selectively opening 
a device on the basis of the board version was needed, since serial numbers are 
unique per board version only.

See the attached .diff files for the modification. NOTE that the modification 
breaks the API.

ftdi_set_interface() should be called before ftdi_usb_open_desc()

The current version does this the other way around, which means that libftdi
will open INTERFACE_A first, then switch to the one passed to Open().
This causes problems if one uses INTERFACE_A for other purposes, spams the 
kernel logs with "did not claim interface X before use", and IIRC will error 
out with libftdi-1.

Add this to prevent type issues in python when using types other than basic int.

Feature needed: If multiple FTDI devices are attached there is no mechanism 
provided by the libmpsse to allow the user to specify the adapter index to be 
used. The serial number is not sufficient since there are chips that don't have 
the serial number set to an unique number.
Attached is a possible patch against libmpsse-1.2-1.tar.gz for implementing 
this feature.

I noticed that the memory usage started to rise exponentially when i disconnect 
the device from the host. The software tries to reconnect to the device by 
calling the Open method.

To reproduce the issue i ran the following code:

#include <mpsse.h>
#include <mcheck.h>

int main()
{
  mtrace();

  struct mpsse_context *Dev = Open(0x0403, 0x6014, I2C, ONE_HUNDRED_KHZ, MSB, IFACE_A, NULL, NULL);
  Stop(Dev);
  Close(Dev);
  Dev = NULL;

  muntrace();
}

The trace log:

Memory not freed:
-----------------
           Address     Size     Caller
0x0000000000137da8    0x128  at ./lib/libusb/libusb/core.c:1594
0x0000000000137ed8     0x10  at ./lib/libusb/libusb/io.c:2323
0x0000000000137ef0     0x10  at ./lib/libusb/libusb/io.c:2323
0x0000000000137f08     0x18  at ./lib/libusb-compat/libusb/core.c:523
0x0000000000137f28        0  at ./lib/libusb-compat/libusb/core.c:420
0x0000000000137f38      0x5  at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000137f48      0x4  at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000137f58   0x1018  at ./lib/libusb-compat/libusb/core.c:217
0x0000000000138f98   0x1034  at ./lib/libusb-compat/libusb/core.c:330
0x0000000000139fd0   0x1034  at ./lib/libusb-compat/libusb/core.c:330
0x000000000013b008   0x1034  at ./lib/libusb-compat/libusb/core.c:330
0x000000000013c040   0x1034  at ./lib/libusb-compat/libusb/core.c:330
0x000000000013d078   0x1034  at ./lib/libusb-compat/libusb/core.c:330
0x000000000013e0b0   0x1034  at ./lib/libusb-compat/libusb/core.c:330
0x000000000013f0e8     0x18  at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f108     0x28  at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f138     0x18  at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f158      0x8  at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f198      0x8  at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f1a8     0x18  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f1c8      0x9  at ./lib/libusb-compat/libusb/core.c:435
0x000000000013f200     0x18  at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f220     0x18  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f240     0x28  at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f270     0x18  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f290     0x18  at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f2c8      0x8  at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f2d8     0x14  at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f2f0     0x10  at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f308     0x18  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f328     0x14  at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f348     0x18  at ./lib/libusb-compat/libusb/core.c:523
0x000000000013f368     0x18  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f388     0x14  at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f3d8     0x17  at ./lib/libusb-compat/libusb/core.c:435
0x000000000013f3f8     0x30  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f430     0x28  at ./lib/libusb-compat/libusb/core.c:420
0x000000000013f490      0x8  at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f4a0     0x18  at ./lib/libusb-compat/libusb/core.c:454
0x000000000013f4e0      0x8  at ./lib/libusb-compat/libusb/core.c:479
0x000000000013f4f0     0x14  at ./lib/libusb-compat/libusb/core.c:420
0x0000000000140f98     0x40  at ./lib/libusb/libusb/core.c:533
0x0000000000140fe0     0x40  at ./lib/libusb/libusb/core.c:533
0x0000000000141028     0x40  at ./lib/libusb/libusb/core.c:533
0x0000000000141070      0x6  at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000141080     0x40  at ./lib/libusb/libusb/core.c:533
0x00000000001410c8      0x6  at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x00000000001410d8     0x40  at ./lib/libusb/libusb/core.c:533
0x0000000000141120      0x8  at ./lib/libusb/libusb/os/linux_usbfs.c:868
0x0000000000141130     0x40  at ./lib/libusb/libusb/core.c:533
0x0000000000141178      0x8  at ./lib/libusb/libusb/os/linux_usbfs.c:868

What am i forgetting to do? Is this an upstream bug?

What steps will reproduce the problem?
1. Download package, untar it, and run ./configure on CentOS 5.9

What is the expected output?
configure can find python include files

What do you see instead?
...
checking /usr/include/pythonoption usability... no
...

What version of the product are you using? On what operating system?
CentOS 5.9

Please provide any additional information below.
My version of python (python 2.4) doesn't support the --version option.  When I 
replaced --version with -V on line 4724 of configure, it worked.

The comment says that pins are set to input/low, however, they are actually set 
to output (trish = 0xFF). This might be dangerous for some hardware.


Section 3.6.2 from:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_
MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf

What steps will reproduce the problem?
case 1. run b.c from issue #10, measure the clock rate
case 2. change the clock rate to 15000000 (15MHz), rebuild and run
case 3. change the clock rate to 15000001 (15.000001MHz), rebuild and run

What is the expected output? What do you see instead?
case 1. expected = 25MHz, seen = 30MHz (bad)
case 2. expected = 15MHz, seen = 15MHz (good)
case 3. expected = 15MHz, seen = 30MHz (bad)

What version of the product are you using? On what operating system?
verified with libmpsse-1.1 and -1.2

Please provide any additional information below.
ubuntu 11.04 running on 3.0.0-23-generic/x64
The hardware in use is the MPSSE-3.3V cable from FTDI based on the FTDI232H

What steps will reproduce the problem?
1. run the attached file with an FT232H attached
2. notice how everything works
3. comment out the WRITE_BEFORE_READ macro to disable the write command

What is the expected output? What do you see instead?
I would expect the read command to work without a preceding write command. 
Instead, the kernel detaches the device with the following message in the dmesg 
output, while the cable is still plugged in and connected to the USB port:

[37074.838315] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now 
disconnected from ttyUSB0
[37074.838335] ftdi_sio 2-1.5:1.0: device disconnected

The read command only works if I write at least 1 byte before. 

What version of the product are you using? On what operating system?
libmpsse-1.2, ubuntu 11.04 amd64 compiled as 32bit

Please provide any additional information below.
I'm using the readymade MPSSE cable from FTDI, only connected to a scope. 

I am also seeing that replacing the Read/Wrie combination with a call to 
"Transfer" causes the kernel to detach the device in a similar fashion.


When plugging in the cable, the usb connection sequence logs as follows:

[37069.942923] usb 2-1.5: new high speed USB device number 16 using ehci_hcd
[37070.040969] ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
[37070.041014] usb 2-1.5: Detected FT232H
[37070.041017] usb 2-1.5: Number of endpoints 2
[37070.041020] usb 2-1.5: Endpoint 1 MaxPacketSize 512
[37070.041024] usb 2-1.5: Endpoint 2 MaxPacketSize 512
[37070.041027] usb 2-1.5: Setting MaxPacketSize 512
[37070.041340] usb 2-1.5: FTDI USB Serial Device converter now attached to 
ttyUSB0

What steps will reproduce the problem?
1. Plug in an FTDI device with multiple interfaces (e.g. FT2232H w/IFACE_A, 
IFACE_B)
2. Connect to the first one (successfully), using e.g. SPI:
mpsseA = OpenIndex(0x0403, 0x6014, SPI0, ONE_MHZ, MSB, IFACE_A, NULL, NULL, 0);
3. Connect to the second one (won't work), using e.g. SPI:
mpsseB = OpenIndex(0x0403, 0x6014, SPI0, ONE_MHZ, MSB, IFACE_B, NULL, NULL, 0);
4. Notice 2nd connection did not work:
(mpsseB == NULL)

What is the expected output? What do you see instead?
Ideally both connections would be valid, up-and-running and I could talk to 2 
separate SPI circuits independently (and/or simultaneously). Instead the second 
connection failed

What version of the product are you using? On what operating system?
Latest SVN as of today (r201), same as libftdi. Using OS X 10.8.4.

Please provide any additional information below.
Asking for IFACE_B first, and then IFACE_A, confirms that the interface 
parameter works, but once I have made the first USB connection (e.g. to 
IFACE_B), I cannot make a 2nd connection to the other interface (IFACE_A in 
this case)

What steps will reproduce the problem?
1. SPI transfer with + 1024 bytes

What is the expected output? What do you see instead?
Its blocking... I expect a result :-)

What version of the product are you using? On what operating system?
libmpsse-1.2-1
Linux lars-pc 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:47:00 UTC 2013 
x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.
There is a bug inside the Transfer function.
Also I had to decrease the SPI_TRANSFER_SIZE.

diff --git a/spi/mpsse.c b/spi/mpsse.c
index 8347b0b..dca3cee 100644
@@ -767,14 +767,14 @@ char *Transfer(struct mpsse_context *mpsse, char *data, 
int size)
                memset(buf, 0, size);

                /* When sending and recieving, FTDI chips don't seem to like large data blocks. Limit the size of each block to SPI_TRANSFER_SIZE */
-               rxsize = size - n;
-               if(rxsize > SPI_TRANSFER_SIZE)
-               {
-                   rxsize = SPI_TRANSFER_SIZE;
-               }

                while(n < size)
                {
+                   rxsize = size - n;
+                   if(rxsize > SPI_TRANSFER_SIZE)
+                   {
+                       rxsize = SPI_TRANSFER_SIZE;
+                   }
                    txdata = build_block_buffer(mpsse, mpsse->txrx, (unsigned char *) (data + n), rxsize, &data_size);
                    if(txdata)
                    {
diff --git a/spi/mpsse.h b/spi/mpsse.h
index cc6da43..1c8234f 100644
@@ -12,7 +12,7 @@

 #define CHUNK_SIZE     65535
 #define SPI_RW_SIZE        (63 * 1024) 
-#define SPI_TRANSFER_SIZE  1024
+#define SPI_TRANSFER_SIZE  512
 #define I2C_TRANSFER_SIZE  64

 #define LATENCY_MS     2

What steps will reproduce the problem?
1. Installed libmpsse-1.2-1 in ubuntu 12.04 LTS
2. Using with the hardware C232HM USB 2.0 Hi-Speed to MPSSE cable.
3. Then ran examples

What is the expected output? 
Should work

What do you see instead?
Failed to open MPSSE: device not found

What version of the product are you using? On what operating system?
libmpsse-1.2-1 in ubuntu 12.04 LTS

Please provide any additional information below.

What steps will reproduce the problem?
1. configure
2. make


What is the expected output? What do you see instead?
[molli123@c64 src]$ make
gcc -Wall -g -O2 -lftdi  -c support.c
gcc -Wall -g -O2 -lftdi  -c mpsse.c
gcc -shared -Wl,-soname,libmpsse.so mpsse.o support.o -o libmpsse.so -lftdi 
/usr/bin/ld: mpsse.o: relocation R_X86_64_32 against `mpsse' can not be used 
when making a shared object; recompile with -fPIC
mpsse.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [mpsse] Error 1


What version of the product are you using? On what operating system?
Version 0.2 on Fedora16

Please provide any additional information below.
simply adding -fPIC to CFLAGS in Makefile is not sufficient since not all CC 
lines in Makefiles are using it ($(CC) -c  $(TARGET)_wrap.c  $(INC))