Lpc2000

Dominic Rath wrote:

>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?
>  
>

I was able to read from RAM "md 0x40000000" and get at the ARM 
peripheral gregs ("md 0xe01fc040"), but could not dump the loader "md 
0x7fffd000" or an part of the Flash above 0x3F.

TomW




-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------