AnsweredAssumed Answered


Question asked by amf on Aug 26, 2016
Latest reply on Aug 30, 2016 by amf

I have a question about the SPI MISO signal functionality.  In the SPItoFTDI, the prologue header and the data buffer are stored together in a single array which is sent via SPI DMA from memory to the SPIH port.  The Win32 catching program for the FTDI UMFT4222EV board prints out that it caught 123 and ABC.  If you look on an oscilloscope at the SPIH signals, the MISO line is active while

the data is sent out over the MOSI line.  


I've got a modified version of this where the prologue header is stored in a different array from the data.  The prologue header is moved to the ADuCM350 SPIH port with programmed I/O whereas the data buffer is moved with the SPI DMA.  In my case, I always see the MISO line staying low.  


My question is about the MISO line functionality and its relation to the FTDI driver calls on the slave side (which are the same calls used in spi_slave_test_slave_side.cpp as in the SPItoFTDI example).  That is, the two main functions called in the Win32 console app are FT4222_SPISlave_GetRxStatus() and FT4222_SPISlave_Read().  


Does the MISO line get toggled at the hardware level, or does the MISO line get toggled by either of these function calls?  Why would the MISO line ever stay low?  I've included some details, attached.  Can you explain a bit about exactly what assumptions we're using in the SPItoFTDI example as far as what is required to be sent from the ADuCM350 SPI master?


...later...after pounding on this some more...


I should say that the above is what happens when I try to use a checksum for the buffer and have the SPI master send using the SPI_MASTER_TRANSFER command (which is the command for when you want to use a checksum).  If one uses simply the command SPI_SHORT_MASTER_NO_TRANSFER, communications works (the MISO line toggles and the Win32 spi_slave_test_slave_side.cpp application catches what is sent).


It's possible to also get communications to work, even with a checksum and the SPI_MASTER_TRANSFER command ... as long as you don't have a prologue (i.e. you stick the prologue header information directly into the first few bytes of an array that also contains your data/checksum).


But no way does it want to work if you have a prologue header and you have a checksum and you try to use SPI_MASTER_TRANSFER?  Could it be a bug?  I think I've tried every possible combination of xfr.Datasize

and BufferPrologue MSByte and LSByte fields for the BufferPrologue's size field.