Re: ftdi_read_data return 0xff

[Rodrigo Rosa <rodrigorosa.lg@xxxxxxxxx>]

On Tue, Feb 8, 2011 at 4:35 AM, Michael Plante <michael.plante@xxxxxxxxx> wrote:

Rodrigo Rosa wrote:
>> I've been taking the commands (0x6E, etc) from AN108.

Yes, I'm just saying that 0x6E is not as easy for me to understand, as it
doesn't really document whether the length is in bits or bytes. �If you
think it's the right command, great. �Since your concern is that it returns
all 0xFF's, maybe you could check that by tying the "TDO/DI" (the name of
the pin being sampled by the FTDI, according to docs) permanently low, and
then repeat with it tied permanently high? �If it's clocking it on the wrong
edge or something, maybe it misses a brief transition?

i enabled loopback (tied TDI to TDO) i tried debugging this code:

sync_mpsse(&ftdic);

while(ftdi_read_data(&ftdic, input_buff, 100) != 0 );

unsigned int aux = 0;

int counter = 0;

numBytesRead = 0;

// -----------------------------------------------------------------------------------------

// �Simple example

// -----------------------------------------------------------------------------------------

�� �while(1)

�� �{

�� � � �// write

�� � � �numBytesToSend = 0;

�� � � �output_buff[numBytesToSend++]=0x6E;

�� � � �output_buff[numBytesToSend++]=0x02;

�� � � �output_buff[numBytesToSend++]=0x80;

�� � � �output_buff[numBytesToSend++]=0x6E;

�� � � �output_buff[numBytesToSend++]=0x00;

�� � � �output_buff[numBytesToSend++]=0x00;

�� � � �numBytesSent = ftdi_write_data(&ftdic, output_buff, numBytesToSend);

�� � � �if(counter++ == 10)

�� � � �{

�� � � � � �sync_mpsse(&ftdic);

�� � � � � �while(ftdi_read_data(&ftdic, input_buff, 100) != 0 );

�� � � � � �counter = 0;

�� � � �}

�� � � �sleep(3);

�� � � �//read

�� � � �numBytesToRead = 5;

�� � � �int i;

�� � � �for(i=0;i<numBytesRead;i++)

�� � � �{

�� � � � � �input_buff[i]=0x00;

�� � � �}

�� � � �aux = ftdic.readbuffer_remaining;

�� � � �numBytesRead = 0;

�� � � �numBytesRead = ftdi_read_data(&ftdic, input_buff, numBytesToRead);

�� �}

changing the values of line1,�line2,�line3,�line4. the first reading get 2 bytes of ones, and after the third loop I still get 2 bytes, but they seem to look like what i expected. For the example code pasted above, I expected 3 ones followed by a zero.

the first read gives me�input_buff[0]==11111111 and input_buff[1]==1111111

the second read gives�input_buff[0]==11101111 and input_buff[1]==1110111

the third and any following loops get input_buff[0]==11101110 and input_buff[1]==1110111. I see the sequence i expected, and if i modify the code i can generate other sequences which are coherent with the code.

i think it makes sense to me getting two bytes of data, one for each time i run the command 0x6E. what i don't understand yet is the content of the returned value...

�

>> i was doing the sync, but not correctly. I was only reading once. Now i
>> write 0xAA and read a lot, check through what was read to see if i find
>> what i wanted. if not i write again and repeat. seems to work ok.

Ok, I'd fiddle with this some more until I started reading exactly how many
bytes I want 99% of the time (it probably won't be 100% of the time,
particularly if the latency timer and timeout are configured aggressively,
which seems pretty necessary for reasonable turnaround, at least with the
synchronous API), and then abstract it in a function. �Let me know when
you're getting exactly how many bytes you expect most of the time.

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?

�

Note that bad commands can't be interpreted until the previous one finishes,
so it will hopefully help you identify the correct value of length (and I
don't know what that is for 0x6E).

>> >> returns: input_buff = [0xcc, 0x33, 0x0, 0x0, 0x0 ...]

You said below you're getting all 0xff's. �What is the 0xcc and 0x33 then?

i didn't get that anymore, i'm trying to reproduce it, but i haven't been successful yet.

�

>> i put in a loop to make the scope work easier, i was just
>> testing if the code had any effect on the TDI pin.

Fair enough, but it would help to know if it behaves differently on each
consecutive loop. �If you were getting out of sync, then you would expect
different answers each time around.

how often would you recommend syncing?

after a given number of ftdi_write_data commands?

�

>> ok, my bad, i'm just getting started with this.
>> the code above returns numBytesRead == 3, with all the reading set to
0xFF
>> (the other values of input_buff are not modified during reading).
>> from AN108 describing 0x6E "The TDO/DI pin is sampled for the duration
>> of TMS and a byte containing the data is passed back at the end of TMS
clocking"
>> shouldn't i get at least one reading different from 0xFF?
>> the scope shows that TDI goes 0 1 0

See above about tying the pin one way or the other. �That would rule out any
clocking issues, I think.

I have to say that I'm confused by their notation "TDO/DI" versus "TDI/DO",
as far as which is which...possibly a stupid question from me, but is it
possible that the pins are swapped? �Probably not, but I need to ask...

the hardware connections are ok. i assumed TDI/DO�refers�to TDI, i connected the ft2232 TDI pin to the TDI pin of my device.

when i was checking this i realized that i haven't been able to get the scope to read anything on TDO. still trying to figure that out.

�

>> i'm working at 20kHz, verified that.

Ok, so you're saying that one cycle is 50 microseconds, and that your +width
is 12.5 microseconds (25%)? �If so, how many bits are high? �Or are you
saying one bit takes 50 microseconds to go out and that one period is 200
microseconds? �Alternatively, could you tell me what your code set the
divisor to? �I guess what I'm saying is "20kHz" is a vague statement without
further qualification -- it could be your periodic waveform, or it could be
your bitrate.

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?

��

Regards,
Michael


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx

isn't this suppose to give me useful info:��ftdi_context::readbuffer_remaining�?
i get zero all the time.

is it just a slot to use to save info?

thanks again!! :)

--
Rodrigo.

---

libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx