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.
>  
>
Debug from reset doesn't work on any LPC2xxx boards we have. If it does 
work on the chip (which I doubt) then one of the many LPC2xxx board 
vendors could gain a technical advantage by producing a board that is 
correctly wired up. Philips don't seem to want to talk about this area - 
we asked a long time ago and received a similar answer to yours.

Regards
Michael

>  
>
>>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
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>