Please use plain text.
Rodrigo Rosa wrote:
>> i enabled loopback (tied TDI to TDO) i tried debugging this code:
While the debugger may be fine for you, the results are not easily conveyed
to the mailing list. If you use printf()'s to debug, you can post the
output to the list and everyone will be on the same page.
>> with the test loop i made i get as many bytes as i expect, but the
>> content of the bytes... do you know of any other doc besides AN108?
No. I know AN108 was sufficient for SPI/MPSSE. I don't know so much about
JTAG mode, but I'm guessing it should be enough.
>> i didn't get that anymore, i'm trying to reproduce it, but i haven't been
successful yet.
Version control?
>> how often would you recommend syncing?
>> after a given number of ftdi_write_data commands?
First of all, note that you should drain the buffer before you write and
after you read. Not in between like you did above, as that's potentially
throwing away valid data. I always sync in association with draining the
buffer, so that is relevant. Also, you're not printing how much you throw
away, so there's no way to know if you're actually getting how much you
want.
Second, you'll have to experiment, but I can tell you what I did, running
the 2232D part with a divisor of 2 (command 0x86, so 2 MHz) and with a
latency timer of 3ms and a usb_*_timeout=200ms. I have two booleans that
allow optional syncing globally before and after everything, but, reviewing
the code, they appear to be disabled in my MPSSE code and it works ok. I
had them all enabled while debugging, and it only hurt throughput, but
nothing else.
However, there are a few places where I sync regardless of the value of
those booleans:
* Right before sending my absolute first MPSSE command
* Right before sending the request for any data (i.e., input or input/output
ops,
but not for output-only ops)
* Right after a read returns fewer bytes than expected (possibly because
it's
truly out of sync, or maybe just because of a time-out. Doesn't matter
why.)
Note that under normal conditions, none of those syncs or purges should
discard any good data. Only when there's an error will it discard anything
possibly useful. A higher level of my protocol will then re-send under
those failure conditions.
>> i set uint clockDivisor = 0x05DB;//Frequency = 60/((1+0x05DB)*2) (MHz) =
20khz
>> with 0x6E and clocks to zero (one clock) i measured a 50 mu sec pulse.
>> assuming that one pulse corresponds to one clock cycle, that's a 20kHz
clock.
>> is that a little better?
Yes. I guess I also missed that you're using the 'H' part. I am using the
'D' part, as it was chosen before 'H' came out. I think I should still be
able to figure it out, though.
At one point you said that:
>> the scope shows that TDI goes 0 1 0
How wide is that '1' pulse on TDI? Does TCK rise or fall in the middle of
the 1 on TDI?
>> i haven't been able to get the scope to read anything on TDO.
Hrm. Has that been the entire time, or just recently? AN108 seems to say
that TDO is what your target device writes out on and what the FT2232 reads
in on, so maybe that's why you're getting 0xFF's? Could you check if it's
being driven weakly (i.e., staying close to a rail but changing a little),
as opposed to not being driven at all?
Regards,
Michael
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com
