On Tue, Feb 8, 2011 at 4:35 AM, Michael Plante <michael.pla...@gmail.com>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+unsubscr...@developer.intra2net.com
>
>
isn't this suppose to give me useful info:
ftdi_context::readbuffer_remaining<http://www.intra2net.com/en/developer/libftdi/documentation/structftdi__context.html#aad05935e91af93e8dbe36781217632bf>
?
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+unsubscr...@developer.intra2net.com
