On Thu, Jan 24, 2019 at 2:17 PM Paul Fertser <[email protected]> wrote:
>
> Hello,
Hello Paul,
thanks for the reply.
> On Thu, Jan 24, 2019 at 09:59:02AM +0100, Antonio Borneo wrote:
> > e.g. "tcl/target/stm32f4x.cfg" defines a second TAP for on-chip boundary
> > scan
> > if {[using_jtag]} {
> > jtag newtap $_CHIPNAME bs -irlen 5
> > }
> > but HLA only accepts a single TAP and does not enable the subcommand
> > "jtag newtap", thus triggering a fatal error in the script.
Writing this sentence I was biased by the HLA based on ST-Link.
ST-Link only manages the first TAP in the chain and does not offer any
feature to use the other TAPs.
But OpenOCD should accept the list of TAPs in the configuration file.
Here the error is that the script uses the direct command "jtag newtap
..." that is specific of transport "jtag"
To be general, the script should instead use the command "swj_newdap
...", as done few lines above.
Tested and works fine, in the sense that the script doesn't trigger
error, the second TAP is taken by OpenOCD, then the ST-Link HLA still
only uses the first TAP and ignores the second, but this is acceptable
and should be left as is. Maybe a new ST-Link version would add
support for multi-TAP.
I will make a patch to fix this.
>
> I think I assumed that HLA would still need to know the JTAG chain
> configuration to be able to talk to the target. So an hla_jtag
> transport must implement "jtag newtap" and pass the relevant data to
> the adapter driver.
>
> Makes sense?
Yes, but with "s/jtag newtap/swj_newdap/".
Thanks
Antonio
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
