Menu
▾
▴
3 Attachments
#9 SPI broken output waveforms
Hi Stephen
Yesterday I tested my software with hardware devices and got a problem. I hope really that you can help here, please.
Today, I've some oscilloscope pictures in attachment.
At first: please see picture 'Clockphase'.
The green/lower curve is the what I measure from the SPI clock output (pin 13 at FT232H). Every seven bits, there is a stumbling block with a longer and a shorter pulse.
The red curve describes my problem: there is a level shifter which is feeded by the FT232H-chip and the red curve is, what the level shifter returns: it swallows one pulse and turns the clock phase by 180°.
Is there something what you can do to fix it?
Seccondly:
Please see picture Chipselect, its a picture from same session. The green curve in the middle is the clock signal, the picture is widely zoomed out. The SPI traffic consists of continious bytetransfers (I'm using the Spi.transactReadWrite(byte...)-method here), that is where the areas between high and low are.
The problem is the lower blue curve, which is the Chipselect-signal. I woul expect it should be low during transmission and rising to high if transmission is ready, but it still low until next transmission.
In picture ChipselectZoomed, there is the blue pulse and at the right side you see the transmission starting.
Well, I can use an other pin for chipselect signal here, but using chip select would be nice and who knows who this causes problems?
Hi Oliver,
the top left corner of the scope trace indicates that you are measuring a 10MHz square wave at 50MS/s. Seems to me the sample rate is too low and what you are seeing is aliasing. Are you able to increase the sample rate?
Agree that the chip select doesn't look right. Will investigate further.
Hi Stephen
Well, the sample rate is 50MS/s, thats right. But the clock frequency is only 2MHz, see the lower side from picture, right from vertical center axis, the t/square is 1µs and there are two clock cycles/square.
I can try an other oscilloscope and will reply later, but I think, 50MS/s should be enough for 2MHz digital signal.
If that's the case then those signals look terrible. I also fail to see why it has anything to do with this project. It seems to be a hardware problem to me.
Have you read the device datasheet? I seem to recall something about the FT232H having open drain outputs.
Of course I read the datasheet. But I does not constructed the existing hardware.
Well, the only oscilloscope probe no an ideal load. But I'm wondering cause the 8-bit-failure-periode and it seems that the FT232 does not need external circuit elements (see circuit in AN180, page 19). And the device seems to switch slow enough, that there are no informations about rising time.
I think I try a test with differing clock frequenyies, maybe it occured at a special frequency or there are some other things which bring cleareness or inspiration.
I was afraid of something like that. My first idea was problem with an internal clock sync or something like that.
Well, I do some tests, maybe I find something of interest...
Hi Stephen, I have something for you. Could this exception be helpful?
It occured in the same program where I created ticket #8. And yes, I disabled load vcp.
Oliver,
you have to improve the way you report issues. It is very difficult to help when you:
1) raise multiple issues within a single ticket
2) use one ticket to refer to a problem in another ticket
Regarding the exception - java.lang.IllegalStateException: Unable to synchronise MPSSE
Firstly, it has nothing to do with VCP/D2XX driver selection. The get here the D2XX driver is talking ok.
At this point the framework has sent a series of initialisation commands to the MPSSE engine (Mpsse.initialise()) and is checking to see they have worked (Mpsse.synchronise()). The code here is pulled straight from AN135 [5.3.1]. Yad2xx does exactly what FTDI recommends.
As to why it is failing I have no idea.
I am starting to think that it may be in your best interest to put the Java part of things on hold for a while and try doing this via the C API. Remove one variable from the equation.
Well, both issues occures in the same testprogramm. I'm sorry for confusing you.
Hi Stephen, here I'm again
I obeyed your advice and tried some samples with the native C library from FTDI and I think I understand your code better.
I've reported the issue to FTDI and get a beta version from there libMPSSE to fic glitch at the clock line, it seems they know about the problem. It's libMPSSE, so I doesn't work with D2XX directly, but this is also just a "wrapper library" for D2XX, only in C.
Well, it's useless to attach the beta libs here cause there are other issues on it. But I think I should report this to you.
Now I also understand the problem with SPI chip select signal but I have no idea about why do you do, what you do. See Line 106-124 in Spi.java.
I would expect that the cs pin keeps it state after calling mpsse.setDataBitsLow/High and. (You call 2x setDataBitsLow(), but so you mean 1x setDataBitsLow() and 1x setDataBitsHigh()? Could that be the issue?) So I don't understand the for-loop.
Hi Oliver,
welcome back.
Haven't used libMPSSE as a source for yad2xx, just the application notes. FTDI do make the source code available at their website. I would be curious as to what change they made to fix the clock glitch. It may be that there is an error in the application notes and it got copied by the libMPSSE writers and myself.
More advanced FTDI devices have 16* I/O pins per channel (xDBUS and xCBUS). Functions setDataBitsLow/High deal with the low and high order bytes of each channel respectively.
Chip select (CS) polarity is configurable and stored in field selectActiveHigh. True means CS, false means /CS. The value for SPI_OUTPUT_PIN_MASK should mean that only the select pin is affected (assumes values for SCK and MOSI are wired to MPSSE, not pin latches, and are not affected by the write).
The loop is there to guarantee a minimum width (1us) de-asserted state for the select pin.
* - FT232H has 18 (+ACBUS8-9). Have not investigated how the extra two bits affects D2XX/yad2xx
Yes, I know, yad2xx does not use the libMPSSE library. But the libMPSSE includes, like yad2xx, the ftd2xx library and just reduce function calling.
I also wondering about this problem cause the API and Chip are for a while available, I expected that such issues are busted times ago. It would be strange if I'm the first developer who recognize this issue. Its imaginalbe that a circuit filters such glitches out (large capacities in wire entanglement, level shifter, galvanic separation, ...), but without it, the glitches will mess up your day.
Yes, the libMPSSE is courious (e.g. enumerations for SPI mode 1 and 3, but theses changes the clock idle level), but if the error is in ft2dxx lib (I've got it also from FTDI with libMPSSE, it's dif), it would be logical that this error occurs also in yad2xx.
Edit: I've compared the files which I've got from FTDI support and which are installed in my driver folder. The file size is always the same, a documentary error seems possible.
Hi Stephen
I’m writing only to prevent that you close it falsely.
But I haven’t very much time to overdone for this, so it still some days.
But something that could be interesting for you:
Today I’ve compared the libMPSSE-code with yours, it seems that there are some differences (e.g. maybe providing SPI mode 1 and 3, but I will meet this point again if I get an answer of an actual support request from FTDI and they give only one single time a command to change CS state).
Last edit: Oliver Lenz 2018-09-03
Hi Stephen
Now I've spend some time with yad2xx code and the libMPSSE-sources, but the last is really confusing me.
At first, see how libMPSSE toggles the cs pin. There is a function defined in file ftdi_spi.c at line 1175, called FT_STATUS SPI_ToggleCS(). (Download here: https://www.ftdichip.com/Support/SoftwareExamples/MPSSE/LibMPSSE-SPI/LibMPSSE-SPI.zip)
I'm really confused about it, to retrace what this library do here is a challenge. I post it here cause I don't know what else, here.
Starting from line 1218, it seems that the guys from FTDI reads the data direction:
direction = (uint8)(config->currentPinState & 0x00FF);//20110718 direction |= \ ((1<<((config->configOptions & SPI_CONFIG_OPTION_CS_MASK)>>2))<<3);But I have no idea why they operate at it in every cs toggle cycle. I would expect that chip select pin configuration is done one time and not touched after.
The definition SPI_CONFIG_OPTION_CS_MASK is an other thing which I don't understand. It is defined as 0b 1110 0 (0x1C, ftdi_spi.h, line 56), but why? To mask a single pin I would expect a single bit (how you did it in Spi.java. This seems to mask all pins, exclude MiSo, Mosi and Clk.
Later, the value from 'direction' is written back into config->currentPinState. But this happens after the the cs state change (starting from line 1225 in ftdi_spi.c):
oldValue = (uint8)((config->currentPinState & 0xFF00)>>8);//20110718 value = ((1<<((config->configOptions & SPI_CONFIG_OPTION_CS_MASK)>>2))<<3); DBG(MSG_DEBUG,"oldValue=0x%x value=0x%x\n",oldValue,value); if((TRUE==state && FALSE==activeLow) || (FALSE==state && TRUE==activeLow)) value = oldValue | value; /* set the CS line high */ if((TRUE==state && TRUE==activeLow) || (FALSE==state && FALSE==activeLow)) value = oldValue & ~value;/* set the CS line low */ config->currentPinState = ((uint16)value<<8) | direction;Are you looking through there?
Hi Stephen
Bad news. I have to give up with FTDI here, at least for now. So I can't help with fixing this issue.
Closed, nothing heard from FTDI.