Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[Randy]

Hello-

I am writing code (in C#) to interface to an FT232H (actually a C232HM-DDHSL-0 cable).  I am using the FTDI FT2XX DLL, its C# wrapper, and MPSSE.

In looking through all the different code examples on the FTDI site, there seems to be a general sequence of commands one sends in order to get the chip set up properly.  And in all of the different versions (C#, C++, VB, Delphi), there is a place where two bad commands are sent in a row, one to 0xAA, and one to 0xAB.  What is the purpose of doing that? 

The code in the examples are all written so that first the bad command is sent, then a routine is called to read the data back.  That data should be two bytes, first 0xFA, then the bogus command byte.  The read routines are generally written such that the queue is interrogated to first see how many bytes are available, and then that many bytes are read, and finally the first two bytes are checked to make sure they byte[0] = 0xFA and byte[1] = <the bad command that was sent>.

After start up in my code, the very first time this bad command sequence is run it always reads some random number of bytes and some random values (though many times it seems to be byte[0] = 0x40 and byte[1] = 0x40.  The second time and all subsequent times that bad commands are sent, it always returns 2 bytes with byte[0] = 0xFA and byte[1] = <bad command>.

Is this the way it is supposed to be working?

What is the purpose of this?

I am writing my code for SPI and while there is a set of functions for MPSSE and SPI, I have not yet gotten a chance to make the C# wrapper.  So I am setting the SPI up in my code.  So far so good.

Thanks,
-Randy

[FTDI Community]

Hello Randy,

The sync procedure allows you to check that the device is definitely in MPSSE mode and is ready to accept the next command. If for example the device was still in UART or 245 FIFO mode, you would not get this response back as these modes would assume your command is just normal data.

After opening the device and doing SetBitMode, you can flush out the buffer using a routine similar to the one below. This might help to avoid those extra bytes at the start.

Code: [Select]

        private byte FlushBuffer()
        {
            ftStatus = myFtdiDevice.GetRxBytesAvailable(ref BytesAvailable); // Get the number of bytes in the receive buffer
            if (ftStatus != FTDI.FT_STATUS.FT_OK)
                return 1;
           
            if(BytesAvailable > 0)
            {
                ftStatus = myFtdiDevice.Read(InputBuffer, BytesAvailable, ref NumBytesRead);  //Read out the data from  receive buffer
                if (ftStatus != FTDI.FT_STATUS.FT_OK)
                    return 1;       // error
                else
                    return 0;       // all bytes successfully read
            }
            else
            {
                return 0;           // there were no bytes to read
            }
        }
You can find some C# example code in AN_411 which is for an I2C Master but could be edited to create an SPI Master instead by changing the series of GPIO and clocking commands within the I2C functions. This would allow you to implement the chip select and data operations.
http://www.ftdichip.com/Support/Documents/AppNotes/AN_411_FTx232H%20MPSSE%20I2C%20Master%20Example%20in%20Csharp.pdf
You can find the description of the commands used by this code in AN_108 below:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf

Thanks,
FTDI Community

[Randy]

Hi-

Using the FlushBuffer() method doesn't seem to make a difference.  I had been putting it after setting the clock division register in the sequence of events.  I added it higher up in the sequence, after SetBitMode() as you suggested.  That didn't make a difference either.  Maybe I'm mixing up a variable somewhere.

Sometimes the second try of sending a bad command also gets more (or less) than 2 bytes.  I will just do the send bad command read result sequence four times instead of two.  That seems to always work, and it takes virtually no extra time.

Thanks,
-Randy