libftdi Archives

Subject: RE: I'm still struggling with SPI.

From: "Michael Plante" <michael.plante@xxxxxxxxx>
To: <libftdi@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 27 Aug 2010 11:41:13 -0500
John Oyler wrote:
>> Then I loop through, trying to read them back. That doesn't quite work,
the first two
>> reads give 0x00, then while trying to read the 3rd address, I get back
the value of
>> the 1st, then while trying to read the 4th I get the value for the 2nd,
and so forth.

Did you get a chance to see (on the scope) if /CS was staying low for the
entire command sequence?  In other words, when you write the register
address out, and then you wait for the reply, does /CS stay active/low in
between, or does it pulse high briefly?  Is the problem intermittent, and,
if so, how often does it work or not?

>> I don't need to read registers though...

I would suggest error checking (by reading the registers) is a good idea.
Additionally, this will tell you if you know how to read things correctly,
and give you confidence on your RSSI reads.

>> For that, I need to set ADBUS4 low, and leave ADBUS3 (the typical chip
select) high.

You need to change pindir to 0x1b then, I think, rather than 0x0b.  ADBUS4
is 0x10.  Otherwise, ADBUS4 will be Hi-Z/input, and will float to whatever
the circuit lets it go to (not looking at schematic at the moment, or I'd
tell you what that is...sorry).

>> I can see some of the ftdi commands that the flashrom coders
>> use, they're in AN108. Those ones even make sense.

Could you elaborate?  By knowing which ones make sense to you, I might be
able to rule out possibilties.

>> Other things, like line 117...
>> That seems like it's just packing a 0x00 into the buffer to send.

Yea, that looks like 0.  The idea is probably that they're trying to make
SCK and MOSI idle low, but I'm not sure.  You could certainly try changing
it to

-       buf[i++] = 0 & ~cs_bits; /* assertive */
+       buf[i++] =     ~cs_bits; /* assertive */

but you MIGHT have to change it back.  Do you know if your SCK is supposed
to idle high or low?  I don't have the datasheet in front of me right now.
I assume you've gone through and chosen all your commands for clocking in
and out on the correct rising/falling edges, as well as LSbit/MSbit first,
rather than just copying their commands, right?  That's 16 different
possibilities there, so the likelihood of getting it right accidentally by
copy&paste is low.  And getting some of those things wrong will sometimes
allow some commands to appear to work and not others.

I just made my code reconfigurable and tried different settings when my
first guess failed.  Bad, I know, but it only increased source line count by
maybe 0.1%. :)  The MPSSE commands are to some extent a bitfield, so it's
not too hard to do that.  Of course, FTDI doesn't spell this out precisely,
but it's not hard to see the pattern.

>> Some of the debug messages I've stripped from this claim that that's
asserting CS# (ADBUS3), but I don't see how.

Chip select, in most (all?) SPI setups is active-low, so setting ADBUS3 to 0
will assert it.  Setting it to 1 will de-assert it.  The slave interprets it
as inverted, but you should still see 0V on the line when you set it to 0,
and 3.3/5.0 when you set it to 1.

>> cs_bits is useless there, and pindir doesn't seem to be the answer
>> it's value of 11, even with inverted logic, would seem to set ADBUS2 low,
not 3, which is MISO.

cs_bits is still used at the end of the function to restore /CS high.  As
far as pindir, yes, that matters.  pindir=0x0b does not set pins high or
low; it sets input versus output.  So MISO is the only one that remains an
input.  The other three (MOSI,SCK,/CS) remain outputs.  It also sets
ADBUS4-7 to inputs, which you've said you don't want (see above...0x1b is

>> I don't know how to use gdb, but it may be time to learn...

Have you tried "ddd"?

Only downside is, last I tried it (~2004), you have to close it and reopen
it when you recompile your code.

>> and I'll hook it up to the oscilloscope tomorrow morning when I'm back at
work. But again...
>> I'm not sure what that will show either, I already know that ADBUS3 is
low, or I'd not
>> get any SPI commands to work, even in the crappy way that they seem to be

Well, maybe.  Could you post a screenshot (or camera-phone photo) of the
scope, with the entire waveform for a single-register read command, showing
everything from the address output to the bytes coming back, including SCK,
MOSI, MISO, and /CS?

>> And I know with some certainty that ADBUS4 (which instead I want to go
low) isn't...

Well, you only need a DMM to know that.  Just set it permanently low and see
if it really is.  Set it permanently high and see if it is.  You need to try
both to really be sure that you're controlling it, though.

>> And this doesn't even take into account that I also need to do
bit-banging on interface B...

Sorry, I haven't tried before.


libftdi - see for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread