On Mon, Feb 7, 2011 at 6:12 PM, Michael Plante
<michael.plante@xxxxxxxxx> wrote:
Rodrigo Rosa wrote:
>> // write
>> numBytesToSend = 0;
>> output_buff[numBytesToSend++]=0x6E;
>> output_buff[numBytesToSend++]=0x01;
>> output_buff[numBytesToSend++]=0x80;
>> output_buff[numBytesToSend++]=0x6E;
>> output_buff[numBytesToSend++]=0x01;
>> output_buff[numBytesToSend++]=0x00;
>> numBytesSent = ftdi_write_data(&ftdic, output_buff, numBytesToSend);
I am not as sure on the 0x6E as I could have been on the 0x1A and 0x2E.
You'll note the docs say that 0x1A's length is actually length-1, and
measured in bits, rather than bytes. Ditto 0x2E. But it's not clear on
0x6E what "length" represents in the docs. Did you ever go look at AN108?
You really need to read that before you go any further; MPSSE is not as
straightforward on the host side as some other modes are.
I've been taking the commands (0x6E, etc) from AN108.
Anyway, you'll need to experiment some. And synchronize by intentionally
sending bad commands periodically (FTCSPI does this, and so does my code).
I will sometimes send 0xAA and expect 0xFA,0xAA, and then the same with
0xAB. Then you just read until you can't read anymore, and make sure you
find where it told you "bad command". In any case, try calling
ftdi_read_data() and ask for more data than you expect back, at least until
you get the hang of what to ACTUALLY expect.
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.
>> returns: input_buff = [0xcc, 0x33, 0x0, 0x0, 0x0 ...]
After how many iterations through the loop? Did the read ever time out,
maybe just sometimes? Have you checked that there isn't more data
available? Do you know that it's not returning what it should? Why is it
in a loop, and how do you know there's not more data waiting to be read at
the end of each loop (or less)?
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.
>> i don't understand what this means. is there any doc regarding return
codes?
input_buff cannot properly be called a return code, so maybe that's why
you're having trouble finding it? However many bytes numBytesRead is (which
you STILL haven't told me) is how many bytes of input_buff was read out of
the FTDI's FIFO, which in turn come off the wire. But how that corresponds
to the number of bits is something I'm not as familiar with because I always
ran MPSSE such that it counted bytes rather than bits (it was still serial,
but only granular to the nearest 8 bits).
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
i haven't found a smart way to do this, i use an entire byte just to clock out one bit on TDI. I do this by running one clock on TMS (setting clock to zero clocks out 1, as you marked) with the value I wanted on TDI. this way I think i can manage to drag the JTAG state machine around. not very happy, but may work.
>> i hooked up a scope to TDI and i'm getting what i expected, sort of... it
a square wave with 25% duty cycle, i expected 50%...
You need to measure period, too. And also say how you configured the
divisor.
i'm working at 20kHz, verified that.
i wanted to send the IDCODE instruction to the JTAG port of my device, in order the verify that the connection is up and working... i think i got the "send and execute JTAG instruction" part, but I still haven't found out how to read a response.
thanks again, i truly appreciate your help.
Regards,
