Drasko DRASKOVIC wrote:
On Tue, Apr 5, 2011 at 9:01 AM, Laurent Gauch <laurent.ga...@amontec.com> wrote:
On Mon, Apr 4, 2011 at 7:51 PM, Øyvind Harboe <oyvind.harboe at zylin.com
<https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
/ Any objections to merging 1,2 and 4?
/>/
/>/ I think #3 needs more discussion or cool-off. My objection is
/>/ that we don't know why this makes things better and it certainly
/>/ seems to hit performance hard.
/
OK, I will open the discussion by question : when do we use
jtag_execute_queue() ?
Based on the answer from Øyvind I had before, I could conclude that it
serves to clock the data back in, while jtag_add_dr_scan() just puts
them in the queue to be shifted out at some point.
jtag_add_xxxxxxx function will add new commands in the command queue.
Note, the command queue could be auto-executed, depending on the
mechanism/ressource of the JTAG adapter.
The jtag_execute_queue function force the execution of the command queue,
and process the response data coming back from the JTAG adapter.
Before comparing a TDO vector, you MUST do a jtag_execute_queue.
So, if this is correct, then we can avoid using jtag_execute_queue()
when we have no data to shift in. But what happens when the TAP will
send us bit as a response to FASTDATA, and we are completely ingnoting
it ? Will it lead to some collision on the data bus and make ftdi
freak out ?
The JTAG layer only scan in and scan out the shift registers, and control
the TAP FSM.
The TAP will only return data if you do a scan .
Here is EJTAG spec on FASTDATA :
Both upload and download accesses are attempted by shifting in a zero
SPrAcc value (to request access completion) and shifting out SPrAcc to
see if the
attempt will be successful (i.e., there was an access pending and a
legal Fastdata area address was used).
Actually, two solutions :
a) checking the SPrAcc
1.send command to shift in zero to SPrAcc (jtag_add_scan)
2.send command to shift out SPrAcc (jtag_add_scan)
3.execute (jtag_execute)
4.compare SPrAcc returned value
5. if SprAcc not 0 goto 2.
6. send command to shift in your DATA
-> goto to 1.
b) unchecking the SPrAcc, but adding specific delay
1.send command to shift in zero to SPrAcc (jtag_add_scan)
2.wait for x delay allowing your specific hardware to accept SPrAcc
3.send command to shift in your DATA
-> goto to 1.
Note: b)2. the wait could be done by soft, or adding delay in the command
queue or ...
A) will be the most secure
B) could be very fast, but should be avoid for generic implementation (not
safe)
Hi Laurent,
this sounds very interesting, and I'd say that in current
mips_ejtag_fastdata_scan() implementation we are doing something
similar to B), but not quite - we never add the delay. However, this
delay is undefined, and might come because of architecture of some
dongles, so we may have situation that somewhere it works, and
somewhere it does not, right ?
The jtag_execute_queue maybe generate enough delay in some case.
But not safe, since in the case of USB JTAGkey the latency delay added
is 1ms, and in the case of USB JTAGkey-2 the latency delay added is
125us ...
It is much better to work on stable TAP state and generate some CLK periods.
Can you please paste here to versions of mips_ejtag_fastdata_scan(),
A) (with shifting out SPrAcc) and B) (with added delay) as you
described them, so I can try them both and test the results.
Not so many time today, but I would try to out something before the end
of the week.
I would change the code by myself but for A) I do not know - should we
use separate field, or SPrAcc can be return in the same field when
sent, like this :
/* fastdata 1-bit register */
fields[0].num_bits = 1;
fields[0].out_value = &spracc;
fields[0].in_value = &r;
But this does not work.
I have to see again MIPS TAP,.
Are you sure about the
fields[0].num_bits = 1;
Does the register not longer, and need to check one bit ???
And for B) I do not know which function we can use for delay ? Maybe
jtag_add_clocks() ?
The best thing would be here if you can paste these two variants, and
I will integrate them, test them and report the results.
Best regards,
Drasko
Regards,
Laurent
http://www.amontec.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
