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)
Laurent
http://www.amontec.com
Amontec JTAGkey-2 from 1.5V to 5V auto-sense USB JTAG interface
Where do we shift out SPrAcc after the R/W operation (error check) ? I
would say nowhere.
Can this lead to errors, and can this be an explanation why
jtag_execute_queue() is necessary ?
BR,
Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
