Øyvind Harboe wrote:
> Q: should dr/irscan throw an error if polling is enabled?
>
> OpenOCD does background polling based on a timer, so
> two consecutive ir/drscan commands could see other
> JTAG operations intervening, wreaking havoc.
>
> Targets such as the OMAP needs to run a sequence
> of jtag commands uninterrupted.
>
> Some ideas:
>
> - implementations must start such sequences by poll off
> and end them with poll on. Ugly, but supported today.
> - define a wrapper tcl proc that handles reading the
> current polling state, turning off polling, executing
> a sequence of commands and then restoring the
> polling status regardless of whether an exception was
> thrown or not. Writing such a wrapper is easy.
> - make all reset event scripts run with background
> events disabled.
>
>
>
>
>
> The ir/drscan also lacks the ability to return the data clocked in, it
> does not support longer than 32 bits scans, and there is no
> statemove/pathmove command + a raft of other shortcomings
> of these commands, but that's really an independant issue.
>
>
>   
I do not think this is so bad really:

The type of target/tap initialisation that needs dr/ir scans to setup 
the jtag chain and controller are run before  the  target can be 
examined. The type of target initialisations that sets memory mapped 
registers with mww are not affected by polling-

Polls, and many other commands,  are not sent to targets that has not 
been examined. So the initial dr/ir scans are not interrupted.

If we want to do manual dr/ir scans after the target has been setup, 
initialised and examined, the it is reasonable that we have to use poll off.

So what I think we need is a delayed target examination, something like 
when defining a target we set a flag  -delay_examine to signal that more 
setup must be done before the targtet can be examined  with  arp_examine.

My två öre,
regards
Magnus

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

Reply via email to