Øyvind Harboe wrote:
On Thu, Mar 3, 2011 at 3:29 PM, Laurent Gauch <[email protected]> wrote:
---
 src/jtag/core.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/src/jtag/core.c b/src/jtag/core.c
index d7e1cce..68c1257 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -871,9 +871,16 @@ static int jtag_reset_callback(enum jtag_event event,
void *priv)
       return ERROR_OK;
 }
 +/* sleep at least us microseconds. When we sleep more than 1000ms we
+ * do an alive sleep, i.e. keep GDB alive. Note that we could starve
+ * GDB if we slept for <1000ms many times.
+ */
 void jtag_sleep(uint32_t us)
 {
-       alive_sleep(us/1000);
+       if (us < 1000)
+               usleep(us);
+       else
+               alive_sleep((us+999)/1000);
 }
 /* Maximum number of enabled JTAG devices we expect in the scan chain,
--
1.7.0.4

But I think the mechanism itself is not so good.
We should not have to touch JTAG level to keep GDB connection alive !.

That's a valid, but orthogonal objection. It would pretty much require
multithreading of OpenOCD.

Dear Harboe,
Yes, you're totally right.
Also, the jtag_sleep should be exclusively used to sleep the JTAG in stable
JTAG STATE, by running some TCK to generate the corresponding delay we want.

This should be enforced today by pathmove requiring start/end
state to be stable states.
Yes, right. But the how we come in stable state is an other story, you know ...

Anyway, adding delays on JTAG level should be corresponding to generating some TCK in stable state, EVER. We never should have to add ANY 'software' delay in the JTAG level , if we do (and I think we do) this is the better way to get instable ISP.

Regards,
Laurent
Amontec JTAGkey-2 HIGH-SPEED USB JTAG USB SPI 1.5V 1.8V 2.5V 3.3V 5V 
auto-sensing IO
http://www.amontec.com  <http://www.amontec.com>





_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to