Rodrigo Rosa wrote:
>> output_buff[numBytesToSend++] = 0x3C;// write TDI and read TDO
>> output_buff[numBytesToSend++] = 0x01;// One byte (or 1 bit?...)
>> output_buff[numBytesToSend++] = 0x8C;// One byte (or 1 bit?...)
Docs say byte for 0x3C, not bit.
>> for(i=0;i<numBytesRead;i++)
>> {
>> input_buff[i]=0x00;
>> }
numBytesRead appears unitialized here. What compiler are you using and
which warning options do you have enabled? Are you ignoring any warnings?
>> if(numBytesRead < 0)
>> printf("Read error!");
>> if(numBytesRead > 0)
This is missing a case for numBytesRead == 0. While in production that may
be tolerable, we are trying to debug here so it'd be nice to see how many
times your do-while loop retries the read.
>> Flushing buffer: 0x3C 0x01 0x8C
Hrm. Maybe you could show how the initial settings are setup? Like
ftdi_set_bitmode, any loopback commands (or none), etc? It's odd that you
seem to be getting exactly what you sent out, since the 0x3C and 0x01 should
be stripped by the MPSSE engine. I also don't know if 0x3C works for JTAG
or not (it might!).
>> occasionally i got
>>
>> Flushing buffer: 0x3C 0x01 0x8C
>> Flushing buffer: 0x3C 0x01 0x8C
>> Flushing buffer: 0x3C
>> Flushing buffer: 0x01 0x8C
>> Flushing buffer: 0x3C 0x01 0x8C
That might be ok. I kept a circular buffer. I'd have to go back and study
the code to figure out how I handled that, but we can deal with that when we
get the other issues sorted out here.
>> i'm having trouble with the sync. i'm doing this:
I'll try looking over your sync, but I might miss something. So I'll first
tell you how I did it and you can go from there. I did the following until
it succeeded, or failed after 4 time-outs (anything other than timeout or
success aborted immediately, kicking it up to a higher protocol layer):
1. read until empty
2. write 0xAA, then write 0xAB, then (optionally) write send-immediate
3. Init: have not found 0xFA, 0xAA, or 0xAB.
4. While not timed out, and not found both bad commands echoed, do:
4a. clear out my local buffer.
4b. read until ftdi_read_data returns 0 or until my local buffer is full
4c. while my local buffer is not empty:
4c(i). search for and delete 0xFA 0xAA, with any number of
intervening bytes, then 0xFA 0xAB, allowing for the
possibility that these may span calls to ftdi_read_data,
thus the flags initialized in step 3.
5. Return status (timeout, success, etc) after maybe printing diagnostics.
The code I wrote is not exactly simple, and relies on other functions which
I can't easily post. It is a little simpler if you only send 0xAA, not
both. Anyway, let me take a look at what you've done.
>> int read_acq = 1;
You only ever set this to 1?
>> // Check if MPSSE sync ok ()
>> int i =0;
>> while(i<ret)
>> {
>> if(input_buff[i]==acq_code)
>> read_acq = 1;
>> if(input_buff[i]==bogus_code)
>> read_bogus = 1;
>> i++;
>> }
I would rewrite this as
for(i=0; i<ret && !read_bogus; i++) {
if(input_buff[i] == acq_code)
read_acq = 1;
else if(input_buff[i] == bogus_code && read_acq)
read_bogus = 1;
else
read_acq = 0; // either 0xFA followed by != 0xAA, else harmless.
}
Note that read_acq can be nonzero while read_bogus might be zero after this
loop if input_buf[ret-1]==0xFA. But only break on read_bogus, as the code
should be written such that that implies read_acq.
>> when i unplug/plug the usb port connecting to the ft2232 minimodule
>> i'm working the sync works ok, i get the 0xFA and the bogus code when
>> i read. that happens only the first time i sync. afterwards, the
>> device only return the bogus code. is this expected or am i doing
>> something wrong with the sync?
I would not expect plugging and unplugging to do anything predictable, given
the current state of libusb. I didn't care about this, because I have the
luxury of knowing my device will not be plugged or unplugged while my
program is running. So I can't easily comment, but hotplug will eventually
be available in the new branch of libusb (v1), when the politics clears out,
and maybe in libftdi-1 shortly thereafter (?).
>> when sync do you use ftdi_usb_purge_buffers ?
Only the first time (during init). I have noticed errors with this if the
device had JUST been plugged in, and IF it's on Windows. I don't recall
seeing such an error on Linux, but the device was *usually* plugged before
power-up and only unplugged after power-down on Linux, so I'm not sure if it
also causes errors on Linux. I am not confident of that particular code
section, but it worked so I didn't mess with it. I had it set up to retry
(in conjunction with a few other APIs) 4 times. I never saw it fail more
than once. Again, this was only in init (i.e., once per
device-open-operation).
>> i'm going home, i've been on this for 13 hours!
Been there, I understand. ;)
>> running instruction 0x3C, which is supposed to write TDI and read TDO
>> there's a little change in TDO when TDI is being driven, looks pretty
>> week.
This can happen if both devices try to drive the same line and one is
driving more strongly than the other. It could indicate a wire swap. I've
seen this on someone else's (real-)RS232 setup, and I've kept an eye out for
it ever since, since it's so easy to overlook during review. In connection
with you not seeing one of the two lines change ever, the hardware might be
worth looking at. But hard to be certain without seeing it. Do you have
any series resistors (even 0-ohm jumpers) on those JTAG lines?
Regards,
Michael
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
