Lpc2000

On Monday 24 October 2005 22:08, Tom Walsh wrote:
> The problem appears to be the time interval between when the JTAG unit
> asserts a hardware RESET and until it is able to seize control of the
> CPU via the tap interface (JTAG).  During that interval, the processor
> runs like hell and hits the abort'ing code.  Finally the JTAG is
> operational, but now the CPU is abort'ed.
>
The BDI should be able to debug the chip right out of reset, if TRST and SRST 
are correctly wired. While developing my own JTAG debug software, I 
experienced a problem with that on a LPC2294. The JTAG port would stay in 
reset while SRST was asserted, independently of TRST. Debugging out of reset 
works by holding SRST asserted and programming the Embedded-ICE unit to enter 
debug. SRST is then deasserted, and the target immediately enters debug 
state. I asked philips support, but they didn't know about a problem with the 
reset lines.

> For some really strange reason, the JTAG has no control over an aborted
> processor?!
>
Did you try to read some configuration registers? You said you couldn't read 
beyond 0x40 - that's where the remapped exception handlers end. Maybe the 
broken software on the chip / instructions executed in data abort caused 
wrong memory to be mapped?

> The chip is not destroyed as I feared, it is merely totally fsck'ed and
> won't work with the tap controller.
>
>
> TomW

Regards,

Dominic