Hello. Before I get into the subject of my message, let me mention the
following mini-patch:
Index: src/jtag/parport.c
===================================================================
--- src/jtag/parport.c (revision 929)
+++ src/jtag/parport.c (working copy)
@@ -101,6 +101,7 @@
{ "wiggler_ntrst_inverted",
0x80, 0x10, 0x02, 0x04,
0x08, 0x01, 0x11, 0x80, 0x80, 0x80, 0x00 },
{ "old_amt_wiggler", 0x80, 0x01, 0x02, 0x04, 0x08, 0x10, 0x11, 0x80,
0x80, 0x80, 0x00 },
+ { "arm-jtag", 0x80, 0x01, 0x02, 0x04, 0x08, 0x10,
0x01, 0x80, 0x80, 0x80, 0x00 },
{ "chameleon", 0x80, 0x00, 0x04, 0x01, 0x02, 0x00,
0x00, 0x80, 0x00, 0x00, 0x00 },
{ "dlc5", 0x10, 0x00, 0x04, 0x02, 0x01,
0x00, 0x00, 0x00, 0x10, 0x10, 0x00 },
{ "triton", 0x80, 0x08, 0x04, 0x01, 0x02,
0x00, 0x00, 0x80, 0x00, 0x00, 0x00 },
I don't actually have such an adapter, but they currently seem to be the
cheapest reasonably-made Wigglers sold in the USA:
http://microcontrollershop.com/product_info.php?currency=USD&products_id=589
A very maddening problem in OpenOCD occurs when one deals with a Feroceon
target with a blank or erased flash, since the undef exception takes over
immediately upon power-on or reset, taking precedence over any DGBRQ, and
preventing the CPU from entering a halted state, thus perpetuating a
chicken and egg dilemma. In this situation, disabling DBGRQ over telnet
has no real effect, because the exception occurs so quickly. This forum
post suggests that it may be possible to generate a Feroceon halt by
manipulating sRST in a specific way:
http://buffalo.nas-central.org/forums/viewtopic.php?p=37774#p37774
However, this is slightly at odds with Byron Bradley's findings here:
http://buffalo.nas-central.org/index.php/JTAG_&_OpenOCD_for_LS-Pro#Unable_to_halt
Interestingly, Byron has found that on some boards, the Feroceon will
indeed halt in this situation, given enough persistence in trying to get
it to do so, while on other boards, a halt in this situation is a lost
cause. The only correlation I could notice was that the halt may be
possible only on boards not using Marvell's reference 10-pin JTAG design,
but a more conventional ARM JTAG wiring, but this is something of a SWAG.
I am posting this appeal for a solution to this list in the hopes that
Nico Pitre or anybody else who might have one may see it and respond.
Thank you.
PS - Yes, I tried all the above methods of generating a halt,
unsuccessfully. I even tried making OpenOCD simulate a clocking signal
on sRST, to no avail.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
