'Warn : Invalid ACK 0x6 in JTAG-DP transaction' warning with Busblaster v2 and OpenOCD
Ram
I have been trying to debug my Pandaboard with a Busblaster v2 module
and OpenOCD for sometime. I get struck at one point after which there
is no avail. The OpenOCD keeps looping and this looks like it is
closely related to 'Warn : Invalid ACK 0x6 in JTAG-DP transaction'
warning message which appears in the logs.
The logs are like,
Open On-Chip Debugger 0.6.0-dev-00180-g444f202 (2011-11-02-23:22)
<snip>
Info : JTAG tap: omap4430.jrc tap/device found: 0x3b95c02f (mfg:
0x017, part: 0xb95c, ver: 0x3)
Info : JTAG tap: omap4430.dap enabled
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Info : JTAG tap: omap4430.m30_dap enabled
Info : JTAG tap: omap4430.m31_dap enabled
Warn : Invalid ACK 0x6 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Polling target failed, GDB will be halted. Polling again in 6300ms
Polling target failed, GDB will be halted. Polling again in 6300ms
^C
Board : Pandaboard (Rev A2)
Debugger Module : Busblaster v2
Debugger SW : OpenOCD
PC Details : Tested with cygwin on Win Vista as well as Fedora 14;
consistent behavior
A similar problem where the OpenOCD finds the JRC but is not able to
connect to the A9 is discussed in
http://groups.google.com/group/pandaboard/browse_thread/thread/15c30dba1bc89b0f/0c904c092d3bd5b5?lnk=gst&q=Invalid+ACK#0c904c092d3bd5b5.
The author had managed to solve it by following instructions from
http://www.tincantools.com/wiki/Compiling_OpenOCD_WinXP. But this
doesn't seem to work for me.
1] I have tried to follow the OpenOCD code and from that my
understanding is that the OpenOCD SW after the discovery of JRC, adds
the different cores to the chain. After this, it attempts to request
for a system and debug power-up request by writing on the DP's CTRL/
STAT register. It requires a acknowledgment from the system and debug
power domain (on the CTRL/STAT register) before proceeding for further
things (on which I have no idea). It is during this read of CTRL/STAT
register that there is a ACK of 0x6. According to the ADI v5
specifications, the only valid ACKs are 0x2 and 0x1. Any idea of why
this reserved ACK is being read ?
2] There is a bug report on https://bugs.launchpad.net/ubuntu/+source/x-loader/+bug/784626
where upgrading a x-loader is known to solve this problem. This
perplexes me on how the JTAG-based debugger is related to x-loader ? I
am sure a debugger might have been used during the development of x-
loader. Any light on this ?
3] A question on the sideline is that the OMAP manual claims to use
IcePick-D on OMAP-4 Series but the OpenOCD scripts correspond to
ICEPick-C Specs. This has been working for lots of people so I don't
think the ICEPick config has anything to do with this error (unless
something is altered in A2 board/Silicon). The only documentation I am
able to find on the ICEPicks are : http://processors.wiki.ti.com/index.php/ICEPICK.
Are there any detailed documentation available, as I find that the
scripts in OpenOCD seem to do more than what is explained in these
documents.
Best Regards,
Ramkumar
David Anders
> connect to the A9 is discussed inhttp://groups.google.com/group/pandaboard/browse_thread/thread/15c30d....
> The author had managed to solve it by following instructions fromhttp://www.tincantools.com/wiki/Compiling_OpenOCD_WinXP. But this
> doesn't seem to work for me.
>
> 1] I have tried to follow the OpenOCD code and from that my
> understanding is that the OpenOCD SW after the discovery of JRC, adds
> the different cores to the chain. After this, it attempts to request
> for a system and debug power-up request by writing on the DP's CTRL/
> STAT register. It requires a acknowledgment from the system and debug
> power domain (on the CTRL/STAT register) before proceeding for further
> things (on which I have no idea). It is during this read of CTRL/STAT
> register that there is a ACK of 0x6. According to the ADI v5
> specifications, the only valid ACKs are 0x2 and 0x1. Any idea of why
> this reserved ACK is being read ?
> 2] There is a bug report onhttps://bugs.launchpad.net/ubuntu/+source/x-loader/+bug/784626
> where upgrading a x-loader is known to solve this problem. This
> perplexes me on how the JTAG-based debugger is related to x-loader ? I
> am sure a debugger might have been used during the development of x-
> loader. Any light on this ?
the jtag pins for most OMAP3 and OMAP4 devices can be pin muxed to be
used for other functions or turned off completely.
the default x-loader for the initial releases of PandaBoard support
had the JTAG pins disabled.
> 3] A question on the sideline is that the OMAP manual claims to use
> IcePick-D on OMAP-4 Series but the OpenOCD scripts correspond to
> ICEPick-C Specs. This has been working for lots of people so I don't
> think the ICEPick config has anything to do with this error (unless
> something is altered in A2 board/Silicon). The only documentation I am
> able to find on the ICEPicks are :http://processors.wiki.ti.com/index.php/ICEPICK.
> Are there any detailed documentation available, as I find that the
> scripts in OpenOCD seem to do more than what is explained in these
> documents.
>
the icepick support in openocd was added to support the BeagleBoard
using OMAP3 which has the C specs.
http://elinux.org/OMAP3530_ICEPICK
the icepick support is a closed specification and generally TI only
provides just enough information directly for open source applications
to utilize a minimal set of funcationality.
Dave
> Best Regards,
> Ramkumar
Ram
I get it know how the x-loader fix was able to solve similar problems.
It is still a bit hazy how the JRC appeared in the scan chain when the
pins weren't muxed in a right manner.
>
> > 3] A question on the sideline is that the OMAP manual claims to use
> > IcePick-D on OMAP-4 Series but the OpenOCD scripts correspond to
> > ICEPick-C Specs. This has been working for lots of people so I don't
> > think the ICEPick config has anything to do with this error (unless
> > something is altered in A2 board/Silicon). The only documentation I am
> > able to find on the ICEPicks are :http://processors.wiki.ti.com/index.php/ICEPICK.
> > Are there any detailed documentation available, as I find that the
> > scripts in OpenOCD seem to do more than what is explained in these
> > documents.
>
> the icepick support in openocd was added to support the BeagleBoard
> using OMAP3 which has the C specs.
>
> http://elinux.org/OMAP3530_ICEPICK
>
> the icepick support is a closed specification and generally TI only
> provides just enough information directly for open source applications
> to utilize a minimal set of funcationality.
It turns out that with ICEPick-D, I am able to connect to the ARM core
quite successfully though there are many times when the polling fails
and had to re-start, which OpenOCD does automatically for me.
I m surprised over the fact that there are many people who have
reported the OpenOCD default scripts for Pandaboard to work well. The
only possible reason I can think of, is they are using a version of
board with ES_1.X silicon version of OMAP4430, which might be using
ICEPick-C. I am not sure. Can some one point me to the OMAP 4430
ES_1.X silicon version TRM so that I can confirm ? I don't seem to
find it.
>
> Dave
>
>
>
>
>
>
>
> > Best Regards,
> > Ramkumar
David Anders
there are no ES1.X pandaboard released to the public, and only a
handful were built for testing.
Dave