[HTC Pico (Explorer)] no.human.being:
The ARM processor always fetches, decodes, executes an instruction, then fetches, decodes and executes the next. There's no way to "halt" it (other than powering it down). If it seems to have halted, it must actually have entered an infinite loop that causes it to execute the same code over and over again without ever getting out and without performing any visible action. Something like that.

sub pc, pc #4

This is the simplest form of infinite loop on an ARM processor. It subtracts 4 (size of one instruction in bytes) from the program counter, so the next fetched instruction is the same. Of course the actual loop will be more complex (e. g. querying a flag whether it is set, if not query it again until it is set).

I could guess that you could automate the "query the processor for the instruction pointer, then perform single-step" process in OpenOCD and put the instruction pointer values somewhere (say in a text file). At the beginning it will start wandering around, going into and out of sub procedures, loops, etc. but towards the end, you will have a (relatively) short section of code that is executed hundreds of millions of times. Then you look at the disassembly what that code is and you'll probably find a conditional branch that is always taken since the condition is always met. Then you can alter the loop (or whatever) in the machine code so that the condition is met and then you'll most likely have fixed the lockup issue. You have just taken out the "wait for condition x"-mechanism (I imagine it somewhat like a "spinlock") where "condition x" is never fullfilled for a "chainloaded HBOOT".

EDIT: Sorry, I didn't read your question properly. I interpreted it something like: "What would you do about the unresponsive issue with JTAG?"

Well without JTAG, I don't know, as you don't see what the processor is doing, which branches it is taking, etc. The MSM7227 HBOOT had a similar issue. It always restored a "known good" HBOOT from what we call the "unmapped memory" area so you could boot into the "chainloaded" HBOOT, it would display its menu, but then "revert" to "stock" HBOOT.

What we call the "unmapped memory" is a memory area that's shared with the Radio (Iguana) so Iguana can place a copy of the unmodified HBOOT partition here. We called it "unmapped memory" since the Android kernel leaves it completely unused unless you specifically "map" it to a device using kernel parameters. If you do so, you'll find lots of "strange stuff" in it that's most likely somehow "generated" by Iguana. We thought for some time that it's a part of NAND since it acts like NAND, but it's probably not. The contents have sections that are very similar to NAND content, but then differ in some bytes. It's very strange and we don't know which purpose it fulfulls, but we think that the words you read from this memory area are not actually "stored" anywhere, but generated by the Iguana on the fly at each read request. Read access probably triggers an interrupt and then Iguana "returns something" there. Write access to this memory does not appear to have any effect (other than a "memory ECC error" interrupt to be thrown), the values are probably just discarded. Next time you read from it, the old values are returned.