On Tue, Aug 19, 2008 at 4:41 AM, Daniel Gimpelevich
<[EMAIL PROTECTED]> wrote:
> 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 },
Committed.
>
> 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.
The above is a bit too undigested for any action to be taken without
having actual hardware.
Do you have any suggestions at this point as to how OpenOCD can
solve this problem?
Can you try to boil down these discussions to the essential and relevant
bits for OpenOCD & post it here?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
