Re: [Openocd-development] questions about irscan/drscan/etc
Makes sense to me :-) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
On Monday 01 June 2009, Duane Ellis wrote: someone asked [something like: But what would a TCL user expect]. Hmm, What does not happen to day, is the ability to scan out data bits and capture them in TCL. Hmm? I thought I saw code returning the captured value of the data register ... is that not complete? Or did I imagine it? What I didn't see was doing that for the *instruction* register. I think the following would be helpful # Goto this state by any means desired, via any random path, really only good for RESET jtag gotostate STATENAME If it's only good for RESET, shouldn't one of the reset primitives handle this? (Maybe a new one?) And guarantee all the relevant state transition hooks fire, as Øyvind mentioned earlier. # Goto next state, must be exactly 1 clock/tms step away, can list multiple states jtag nextstate STATENAME [... more STATENAMEs] That is, just give a state path? So for example part of a Zero-Bit Scan (ZBS) would be: jtag nextstate DRSELECT DRCAPTURE DREXIT1 DRUPDATE I'd think that the rule I mentioned before -- about always needing to end in a non-SHIFT (and, per Øyvind, non-RESET) stable state -- should apply here too. (UPDATE: Hmm, not if you're proposing an entirely queued interface. If the nextstate thing were immediate, it would apply.) # Tell this tap to do a specific scan type # Tapstate must be CAPTUREDR or CAPTUREIR otherwise error jtag scan -type DR|IR -bitlen NBITS -iarray ARRAYNAME -oarray ARRAYNAME -endstate NAME Hmm, now you're getting into rewriting the entire set of lowlevel JTAG calls. :) # Simplistic ir scans - of only a few bits jtag scan -type IR -bitlen 5 -value VALUE # Run clocks in RESET, IRPAUSE, DRPAUSE, or IDLE/RUN state jtag idleclocsk NCLOCKS # Finally, jtag execute AH!! This batched model I think I like. Though I think I'd package it differently, and in a more TCLish way. Instead of queueing a bunch of JTAG operations *inside* the OpenOCD engine ... have a array representation of them, which can be saved and then interpreted by jtag execute $saved. # NOTE: The above commands are global # and do not account for any tap in bypass, their view is # effectively at the end of the dongle cable. # Wiggle TRST and/or SRST pins jtag set TRST 0 jtag set TRST 1 jtag set SRST 0 jtag set SRST 1 Examples jtag set TRST 0 jtag set SRST 0 sleep 500 jtag set TRST 1 jtag set SRST 1 All that stuff is doable with current interfaces. jtag gotostate RESET jtag gotostate SHIFTIR # ? not sure here, the idea is to put the 5 bit value 0x0c in the IR register jtag scan -type IR -bitlen 5 -value 0x0c -endstate EXITIR # Scan out, 35 bits into MYBITS - with, TDI = 1 during the shift. jtag gotostate CAPTUREDR jtag scan -type DR -bitlen 35 -tdi 1 -oarray MYBITS -endstate EXITDR Ditto, I think. But -- no jtag execute? == -Duane == ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
# Finally, jtag execute AH!! This batched model I think I like. Though I think I'd package it differently, and in a more TCLish way. Instead of queueing a bunch of JTAG operations *inside* the OpenOCD engine ... have a array representation of them, which can be saved and then interpreted by jtag execute $saved. Actually this may be *required* to get things to work right. Otherwise the script has to turn off timer based polling... Sounds like a rewrite of dr/irscan is upcoming... :-) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] questions about irscan/drscan/etc
So I'm trying to whack the user guide into shape, and those two commands leave me a bit puzzled. Ergo, some questions and a few observations. In no particular order here: drscan and irscan ... hmm, these seem to require numeric TAP identifiers, vs the names preferred elsewhere. == Worth fixing at some point, yes? drscan and irscan ... what's the final state if the caller doesn't specify -endstate ...? I hope/expect IDLE. == if not specified, worth IMO doing so; random == bad. drscan and irscan ... as noted in [1] (top of p. 3-6) there are only six steady states, with TMS fixed, where TCK doesn't start walking through the JTAG state machine. Of those, the two SHIFT states change register contents, thus presumably walking through device state machines. And RESET is all kinds of special case. Seems to me this adds up to advice that the endstate should be either IDLE, DRPAUSE, or IRPAUSE. Because some JTAG adapters will use free running TCK (yes?), and using non-steady states means the TCL code can't rely on reproducible behavior otherwise... == if so, it might be worth rejecting other endstates. Who knows, maybe there are some bugs hiding there. drscan ... drscan 0 16 0x1234 16 0x5678, is this equivalent to drscan 0 32 0x12345678? With the 0x12... bits going out first, in both cases (not the 0x87... ones)? drscan ... observation, platforms with 64 bit integers are going to be able to say drscan 0 38 0x123456789A but that won't work on most systems. Ergo I'll give guidance not to use fields of more than 32 bits, to avoid proliferation of nonportable scripts. drscan ... can only send bits to one TAP. Presumably all others must be in bypass? And so the single bit written to their bypass register is don't care. == probably worth adding code to verify only that one device is out of bypass, yes? irscan ... observation, this doesn't seem to accomodate arbitrary length instructions. (Even if I got docs for that C55x DSP's JTAG, I couldn't feed it 38-bit instruction words in any portable way.) == possibly worth having this share the same code that drscan uses. For now I'll just warn about not being able to issue large instructions. This doesn't seem like a big deal; just worth noting. irscan ... observation, this supports chatting with multiple devices (the others seem to get BYPASS). Which means it's more powerful than DRSCAN, which only supports one device. == again, possibly worth sharing code. I suspect not; since there's no error checking on lengths for data registers, it' be too easy to cause problems. So it'd be good enough to just verify that only one TAP is out of BYPASS mode during a drscan. Hmm, and: tms_sequence ... we plan this to go away by 0.4 at the latest, yes? (If not 0.3 ...) I there's any agreement about those may be ... comments, I'll provide a patch with relevant FIXME comments so the issues don't get lost. (Then maybe fix some.) That's all for now. :) - dave [1] http://focus.ti.com/lit/an/ssya002c/ssya002c.pdf ... there's a ...2d.pdf too, rev d; you'll see the page size/format issues if you look. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
On Mon, Jun 1, 2009 at 10:09 AM, David Brownell davi...@pacbell.net wrote: So I'm trying to whack the user guide into shape, and those two commands leave me a bit puzzled. Ergo, some questions and a few observations. In no particular order here: drscan and irscan ... hmm, these seem to require numeric TAP identifiers, vs the names preferred elsewhere. == Worth fixing at some point, yes? drscan and irscan ... what's the final state if the caller doesn't specify -endstate ...? I hope/expect IDLE. :-) I've suggested to retire jtag_add_end_state() which defines the default end state... == if not specified, worth IMO doing so; random == bad. drscan and irscan ... as noted in [1] (top of p. 3-6) there are only six steady states, with TMS fixed, where TCK doesn't start walking through the JTAG state machine. Of those, the two SHIFT states change register contents, thus presumably walking through device state machines. And RESET is all kinds of special case. Seems to me this adds up to advice that the endstate should be either IDLE, DRPAUSE, or IRPAUSE. DRPAUSE and IRPAUSE are illegal end states for lots of good reasons... w.r.t. irscan/drscan they should be rewritten to use the same code + fix the various and sundry headaches that you have pointed out. Perhaps post 0.2? tms_sequence ... we plan this to go away by 0.4 at the latest, yes? (If not 0.3 ...) If not before 0.2? It could be made a debug feature, i.e. if you enable JTAG_DEBUG_IO(sp?). -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
On Monday 01 June 2009, Øyvind Harboe wrote: On Mon, Jun 1, 2009 at 10:09 AM, David Brownell davi...@pacbell.net wrote: So I'm trying to whack the user guide into shape, and those two commands leave me a bit puzzled. Ergo, some questions and a few observations. In no particular order here: drscan and irscan ... hmm, these seem to require numeric TAP identifiers, vs the names preferred elsewhere. == Worth fixing at some point, yes? drscan and irscan ... what's the final state if the caller doesn't specify -endstate ...? I hope/expect IDLE. :-) I've suggested to retire jtag_add_end_state() which defines the default end state... I've followed *some* of that discussion, but that seems to be focussed on the innards. For the moment I'm coming at this problem top-down: what does the TCL-user see? It should be reproducible and fully predictable, IMO. Questions about how the C code can unconfuse itself are good, but separable. In both drscan and irscan commands we see this initialization: endstate = cmd_queue_end_state; Which seems as likely to be garbage as anything else. I guess I'm suggesting it just get initialized to TAP_IDLE. (And will be submitting a patch to do that, I think.) == if not specified, worth IMO doing so; random == bad. drscan and irscan ... as noted in [1] (top of p. 3-6) there are only six steady states, with TMS fixed, where TCK doesn't start walking through the JTAG state machine. Of those, the two SHIFT states change register contents, thus presumably walking through device state machines. And RESET is all kinds of special case. Seems to me this adds up to advice that the endstate should be either IDLE, DRPAUSE, or IRPAUSE. DRPAUSE and IRPAUSE are illegal end states for lots of good reasons... The -endstate flag seems misnamed. -nextstate would stop implying it's a *terminal* state. For intermediate states those are perfectly valid ... and are even designed to be safe places to pause state machines. The whole point of that flag is to specify some of the key *intermediate* states. Without specifying them, it's not possible to do things like load instruction, then load the data to which it applies ... or load one instruction and its data, then the next instruction and its data. At least, not without entering the Run/Idle state ... which can have undesirable side effects. Note that the ICEpick/JRC code must use both DRPAUSE and IRPAUSE in order to work. And the limited public docs I've found on the topic (OMAP-L137) specify those states very explicitly. ... all that said, my question stands: does it make sense to support anything other than IDLE, DRPAUSE, and IRPAUSE for the current -endstate param value? AFAICT the only way such states would make sense is if the TCL script somehow knew that the adapter didn't use a free running JTAG clock. That seems unlikely to be a safe assumption in the long term. w.r.t. irscan/drscan they should be rewritten to use the same code + fix the various and sundry headaches that you have pointed out. Perhaps post 0.2? I'd like to fix the random endstate issue before 0.2, and maybe verify for drscan verify that only one TAP is out of bypass. But for the other points, probably post-0.2 is fine. tms_sequence ... we plan this to go away by 0.4 at the latest, yes? (If not 0.3 ...) If not before 0.2? It could be made a debug feature, i.e. if you enable JTAG_DEBUG_IO(sp?). I have no objection to it vanishing completely, so long as nobody turns up ongoing issues with the current default (short) transition tables. I think what I'll do for now is just not document it. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
Why not remove -endstate and always use DR/IRPAUSE respectively? ... all that said, my question stands: does it make sense to support anything other than IDLE, DRPAUSE, and IRPAUSE for the current -endstate param value? IMHO, no. (I was confusing SHIFTDR and DRPAUSE in previous post...) I'd like to fix the random endstate issue before 0.2, and maybe verify for drscan verify that only one TAP is out of bypass. But for the other points, probably post-0.2 is fine. I love it that you call it random endstate which is essentially my objection to jtag_add_end_state() in the first place. It just makes the endstate more or less random :-) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
On Monday 01 June 2009, Øyvind Harboe wrote: Why not remove -endstate and always use DR/IRPAUSE respectively? ... all that said, my question stands: does it make sense to support anything other than IDLE, DRPAUSE, and IRPAUSE for the current -endstate param value? IMHO, no. (I was confusing SHIFTDR and DRPAUSE in previous post...) Yeah, SHIFTDR would be a *really* bad state to be in when exiting drscan! Similarly SHIFTIR/irscan. ;) I'd like to fix the random endstate issue before 0.2, and maybe verify for drscan verify that only one TAP is out of bypass. But for the other points, probably post-0.2 is fine. I love it that you call it random endstate which is essentially my objection to jtag_add_end_state() in the first place. It just makes the endstate more or less random :-) Yeah, unpredictability is ungood ... I'm not going to comment on your proposal about the C versions of the JTAG calls, since I don't really know how they're used. It does however make sense to me that developers say what the endstate should be, as part of queueing an operation. Expecting someone else to choose that is error prone. That might be one of the points you were making. The mechanism for saying what that state should be is just a bit beyond my level of familiarity with that code ... always explicit has clear advantages, but then so might default RUN/IDLE, override anything else. ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
On Monday 01 June 2009, David Brownell wrote: drscan ... drscan 0 16 0x1234 16 0x5678, is this equivalent to drscan 0 32 0x12345678? With the 0x12... bits going out first, in both cases (not the 0x87... ones)? Any answers to these questions? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
someone asked [something like: But what would a TCL user expect]. Hmm, What does not happen to day, is the ability to scan out data bits and capture them in TCL. I think the following would be helpful # Goto this state by any means desired, via any random path, really only good for RESET jtag gotostate STATENAME # Goto next state, must be exactly 1 clock/tms step away, can list multiple states jtag nextstate STATENAME [... more STATENAMEs] # Tell this tap to do a specific scan type # Tapstate must be CAPTUREDR or CAPTUREIR otherwise error jtag scan -type DR|IR -bitlen NBITS -iarray ARRAYNAME -oarray ARRAYNAME -endstate NAME # Simplistic ir scans - of only a few bits jtag scan -type IR -bitlen 5 -value VALUE # Run clocks in RESET, IRPAUSE, DRPAUSE, or IDLE/RUN state jtag idleclocsk NCLOCKS # Finally, jtag execute # NOTE: The above commands are global # and do not account for any tap in bypass, their view is # effectively at the end of the dongle cable. # Wiggle TRST and/or SRST pins jtag set TRST 0 jtag set TRST 1 jtag set SRST 0 jtag set SRST 1 Examples jtag set TRST 0 jtag set SRST 0 sleep 500 jtag set TRST 1 jtag set SRST 1 jtag gotostate RESET jtag gotostate SHIFTIR # ? not sure here, the idea is to put the 5 bit value 0x0c in the IR register jtag scan -type IR -bitlen 5 -value 0x0c -endstate EXITIR # Scan out, 35 bits into MYBITS - with, TDI = 1 during the shift. jtag gotostate CAPTUREDR jtag scan -type DR -bitlen 35 -tdi 1 -oarray MYBITS -endstate EXITDR == -Duane == ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
