Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

destroyed LPC2138 via software

destroyed LPC2138 via software

2005-10-24 by Tom Walsh

This is not good.  I ran some code on the LPC2138 board of mine to track 
down a Data Abort that was being thrown.  Merely commenting out sections 
of code.  Now, after running that code on two boards, dumping memory via 
BDI2000 + JTAG I get a "Data Abort" when it attempts to dump anything 
above 0x0000:0040!

Anyone else run into this?  That is it possible to destroy an LPC2000 
chip via software?

TomW

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

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Tom Walsh

Tom Walsh wrote:

>This is not good.  I ran some code on the LPC2138 board of mine to track 
>down a Data Abort that was being thrown.  Merely commenting out sections 
>of code.  Now, after running that code on two boards, dumping memory via 
>BDI2000 + JTAG I get a "Data Abort" when it attempts to dump anything 
>above 0x0000:0040!
>
>Anyone else run into this?  That is it possible to destroy an LPC2000 
>chip via software?
>
>  
>
Further info, I just destroyed the second board's processor with the 
same code.  I thought maybe it was a bad solder or clock or something on 
the first board.  But, this code also appears to have destroyed the 
second LPC2138 chip.

I can connect and work with the LPC2106 just fine though.

TomW


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

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Tom Walsh

Tom Walsh wrote:

>This is not good.  I ran some code on the LPC2138 board of mine to track 
>down a Data Abort that was being thrown.  Merely commenting out sections 
>of code.  Now, after running that code on two boards, dumping memory via 
>BDI2000 + JTAG I get a "Data Abort" when it attempts to dump anything 
>above 0x0000:0040!
>
>Anyone else run into this?  That is it possible to destroy an LPC2000 
>chip via software?
>
>  
>
Nothing like answering my own question.

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.

For some really strange reason, the JTAG has no control over an aborted 
processor?!

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


TomW

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

RE: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Lowry, Jeff

I've had this happen.  What I had to do was reset the chip with P0.14 low to force it into ISP mode.  I then manually did the ISP commands via RX0/TX0 to erase the chip.  Once erased the JTAG will take control ok.
Show quoted textHide quoted text
	-----Original Message-----
	From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf Of Tom Walsh
	Sent: Monday, October 24, 2005 1:09 PM
	To: lpc2000@yahoogroups.com
	Subject: Re: [lpc2000] destroyed LPC2138 via software
	
	
	Tom Walsh wrote:
	
	>This is not good.  I ran some code on the LPC2138 board of mine to track 
	>down a Data Abort that was being thrown.  Merely commenting out sections 
	>of code.  Now, after running that code on two boards, dumping memory via 
	>BDI2000 + JTAG I get a "Data Abort" when it attempts to dump anything 
	>above 0x0000:0040!
	>
	>Anyone else run into this?  That is it possible to destroy an LPC2000 
	>chip via software?
	>
	>  
	>
	Nothing like answering my own question.
	
	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.
	
	For some really strange reason, the JTAG has no control over an aborted 
	processor?!
	
	The chip is not destroyed as I feared, it is merely totally fsck'ed and 
	won't work with the tap controller.
	
	
	TomW
	
	-- 
	Tom Walsh - WN3L - Embedded Systems Consultant
	http://openhardware.net, http://cyberiansoftware.com
	"Windows? No thanks, I have work to do..."
	----------------------------------------------------
	
	
	
	
	
	SPONSORED LINKS 
Microprocessor <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=ZrDj5MELfXYZPi2RnIlCBA>  	Microcontrollers <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=1O_CbLXBJMjWPA7W8Zss4w>  	8051 microprocessor <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=Y5kxisV_d8EObFRD_hDVDQ>  	

________________________________

	YAHOO! GROUPS LINKS 


		
	*	 Visit your group "lpc2000 <http://groups.yahoo.com/group/lpc2000> " on the web.
		  
	*	 To unsubscribe from this group, send an email to:
		 lpc2000-unsubscribe@yahoogroups.com <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
		  
	*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 


________________________________




[Non-text portions of this message have been removed]

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Ghazan Haider

So can you now reflash the chip with something else
via either JTAG or the serial flasher?

I have a 2138 header and you worry me.


--- Tom Walsh <tom@...> wrote:
Show quoted textHide quoted text
> Tom Walsh wrote:
> 
> >This is not good.  I ran some code on the LPC2138
> board of mine to track 
> >down a Data Abort that was being thrown.  Merely
> commenting out sections 
> >of code.  Now, after running that code on two
> boards, dumping memory via 
> >BDI2000 + JTAG I get a "Data Abort" when it
> attempts to dump anything 
> >above 0x0000:0040!
> >
> >Anyone else run into this?  That is it possible to
> destroy an LPC2000 
> >chip via software?
> >
> >  
> >
> Nothing like answering my own question.
> 
> 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.
> 
> For some really strange reason, the JTAG has no
> control over an aborted 
> processor?!
> 
> The chip is not destroyed as I feared, it is merely
> totally fsck'ed and 
> won't work with the tap controller.
> 
> 
> TomW
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
> 
> 
>

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Dominic Rath

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

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Richard Duits

You can also enter the JTAG debugger while in the bootloader code. This 
way you do not need to erase the chip via the serial lines (which are 
inaccessable on my board). I always put a jumper on the board to pull 
P0.14 low when I screw something up badly. Also JTAG programming does 
not work well when you use the idle mode, so it helps to first force it 
in bootloader mode and then program the chip with the JTAG programmer.


Lowry, Jeff wrote:
Show quoted textHide quoted text
> I've had this happen.  What I had to do was reset the chip with P0.14 
> low to force it into ISP mode.  I then manually did the ISP commands 
> via RX0/TX0 to erase the chip.  Once erased the JTAG will take control ok.
>
>       -----Original Message-----
>       From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] 
> On Behalf Of Tom Walsh
>       Sent: Monday, October 24, 2005 1:09 PM
>       To: lpc2000@yahoogroups.com
>       Subject: Re: [lpc2000] destroyed LPC2138 via software
>      
>      
>       Tom Walsh wrote:
>      
>       >This is not good.  I ran some code on the LPC2138 board of mine 
> to track
>       >down a Data Abort that was being thrown.  Merely commenting out 
> sections
>       >of code.  Now, after running that code on two boards, dumping 
> memory via
>       >BDI2000 + JTAG I get a "Data Abort" when it attempts to dump 
> anything
>       >above 0x0000:0040!
>       >
>       >Anyone else run into this?  That is it possible to destroy an 
> LPC2000
>       >chip via software?
>       >
>       > 
>       >
>       Nothing like answering my own question.
>      
>       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.
>      
>       For some really strange reason, the JTAG has no control over an 
> aborted
>       processor?!
>      
>       The chip is not destroyed as I feared, it is merely totally 
> fsck'ed and
>       won't work with the tap controller.
>      
>      
>       TomW
>      
>       --
>       Tom Walsh - WN3L - Embedded Systems Consultant
>       http://openhardware.net, http://cyberiansoftware.com
>       "Windows? No thanks, I have work to do..."
>       ----------------------------------------------------
>      
>      
>      
>      
>      
>       SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=ZrDj5MELfXYZPi2RnIlCBA 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=ZrDj5MELfXYZPi2RnIlCBA>>  
>       Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=1O_CbLXBJMjWPA7W8Zss4w 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=1O_CbLXBJMjWPA7W8Zss4w>>  
>       8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=Y5kxisV_d8EObFRD_hDVDQ 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=8051+microprocessor&c=3&s=67&.sig=Y5kxisV_d8EObFRD_hDVDQ>>  
>      
>
> ________________________________
>
>       YAHOO! GROUPS LINKS
>
>
>            
>       *      Visit your group "lpc2000 
> <http://groups.yahoo.com/group/lpc2000> " on the web.
>              
>       *      To unsubscribe from this group, send an email to:
>             lpc2000-unsubscribe@yahoogroups.com 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>              
>       *      Your use of Yahoo! Groups is subject to the Yahoo! Terms 
> of Service <http://docs.yahoo.com/info/terms/> .
>
>
> ________________________________
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Tom Walsh

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..."
----------------------------------------------------

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Tom Walsh

Lowry, Jeff wrote:

>I've had this happen.  What I had to do was reset the chip with P0.14 low to force it into ISP mode.  I then manually did the ISP commands via RX0/TX0 to erase the chip.  Once erased the JTAG will take control ok.
>
>  
>
Yeah, that is what I ultimately had to do.

Interesting that the BDI2000 would not stop the LPC2138 from executing 
code.  According to the manual, the "STARTUP RESET" is supposed to stop 
it from executing any instructions out of "RESET HARD 500".  I did not 
use the "WAIT".

This really scared me, since this is the first I've build anything with 
an LCP2xxx chip in it, I was afraid that something nasty had happened 
(burnt core).

TomW



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

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Richard Duits

I also had some trouble reading the flash after triggering the INTPOLAR 
or INTMODE bug in the LPC2294. Don't know if this was the cause, but it 
was solved after I used the work around.

Richard Duits.


Tom Walsh wrote:
Show quoted textHide quoted text
> Lowry, Jeff wrote:
>
> >I've had this happen.  What I had to do was reset the chip with P0.14 
> low to force it into ISP mode.  I then manually did the ISP commands 
> via RX0/TX0 to erase the chip.  Once erased the JTAG will take control ok.
> >
> > 
> >
> Yeah, that is what I ultimately had to do.
>
> Interesting that the BDI2000 would not stop the LPC2138 from executing
> code.  According to the manual, the "STARTUP RESET" is supposed to stop
> it from executing any instructions out of "RESET HARD 500".  I did not
> use the "WAIT".
>
> This really scared me, since this is the first I've build anything with
> an LCP2xxx chip in it, I was afraid that something nasty had happened
> (burnt core).
>
> TomW
>
>
>
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

Re: [lpc2000] destroyed LPC2138 via software

2005-10-24 by Tom Walsh

Richard Duits wrote:

>You can also enter the JTAG debugger while in the bootloader code. This 
>way you do not need to erase the chip via the serial lines (which are 
>inaccessable on my board). I always put a jumper on the board to pull 
>P0.14 low when I screw something up badly. Also JTAG programming does 
>not work well when you use the idle mode, so it helps to first force it 
>in bootloader mode and then program the chip with the JTAG programmer.
>
>
>  
>
Thank you, that is a good tip:  hold down the P0.14 line while telling 
the BDI2000 to "reset halt" and it clears the problem enough that I can 
reprogram the flash from the JTAG.

TomW


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

Re: [lpc2000] destroyed LPC2138 via software

2005-10-25 by Michael Johnson

Hi,

The LPC2000 chips don't support debug from reset (or at least we've 
never seen one that can). By the time that a debugger has got control, 
the chip will have executed many instructions - including ones that 
could turn off the JTAG port, abort, turn on interrupts etc. There are a 
couple of workarounds to this

- Use the serial port bootloader to erase the flash before each debug 
session.

- Stopping the user program in flash from executing by
  - using the P0.14 mechanism
  - putting an invalid checksum in the interrupt vectors
  - modifiying your reset exception handler so that it goes into an 
endless loop
and then get your debugger to start executing from the code that your 
real reset handler will call. This can usually be arranged by setting 
the entrypoint given to the link command line.

Regards
Michael
Show quoted textHide quoted text
>Richard Duits wrote:
>
>  
>
>>You can also enter the JTAG debugger while in the bootloader code. This 
>>way you do not need to erase the chip via the serial lines (which are 
>>inaccessable on my board). I always put a jumper on the board to pull 
>>P0.14 low when I screw something up badly. Also JTAG programming does 
>>not work well when you use the idle mode, so it helps to first force it 
>>in bootloader mode and then program the chip with the JTAG programmer.
>>
>>
>> 
>>
>>    
>>
>Thank you, that is a good tip:  hold down the P0.14 line while telling 
>the BDI2000 to "reset halt" and it clears the problem enough that I can 
>reprogram the flash from the JTAG.
>
>TomW
>
>
>  
>

Re: [lpc2000] destroyed LPC2138 via software

2005-10-25 by Michael Johnson

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
Show quoted textHide quoted text
>  
>
>>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
>
>
>
> 
>
>
>  
>

Re: destroyed LPC2138 via software

2005-10-25 by derbaier

--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
>

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

ARM Application Note 31 talks about debugging directly from RESET, so
it *can* be done. I am just getting started using Phillip's products,
but I used to work for a chip manufacturer that used embedded ARM
cores, and we also had problems with our earlier reference design
circuit boards debugging from RESET. The ARM7TDMI can be debugged
directly from reset, but it does take a correct circuit board and JTAG
pod design to do it since JTAG has to come out of RESET before ARM
comes out of reset accord to AN31. After we reworked our reference
design circuit board hardware, we were able to debug software out of
reset.  That was a really critical necessity at the time, since we had
some write once registers for system configuration that needed to be
written to very early in the normal boot sequence. If they were
written before the debugger got control, it was too late to debug any
difficulties related to that part of the system configuration.

--Dave

Re: [lpc2000] Re: destroyed LPC2138 via software

2005-10-25 by Michael Johnson

derbaier wrote:

>--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
>  
>
>
>  
>
>>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
>>
>>    
>>
>
>ARM Application Note 31 talks about debugging directly from RESET, so
>it *can* be done. I am just getting started using Phillip's products,
>but I used to work for a chip manufacturer that used embedded ARM
>cores, and we also had problems with our earlier reference design
>circuit boards debugging from RESET. The ARM7TDMI can be debugged
>directly from reset, but it does take a correct circuit board and JTAG
>pod design to do it since JTAG has to come out of RESET before ARM
>comes out of reset accord to AN31. After we reworked our reference
>design circuit board hardware, we were able to debug software out of
>reset.  That was a really critical necessity at the time, since we had
>some write once registers for system configuration that needed to be
>written to very early in the normal boot sequence. If they were
>written before the debugger got control, it was too late to debug any
>difficulties related to that part of the system configuration.
>  
>
I know that other ARM devices/boards can be debugged from reset, we have 
quite a few of them. Perhaps the LPC2xxxx boards we have (made by 
theARMPatch, IAR, Olimex, Keil and Nohau) have all got the reset wiring 
wrong - but I doubt it.

Regards
Michael
Show quoted textHide quoted text
>--Dave
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Re: destroyed LPC2138 via software

2005-10-25 by derbaier

--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
> >
> >ARM Application Note 31 talks about debugging directly from RESET, so
> >it *can* be done. I am just getting started using Phillip's products,
> >but I used to work for a chip manufacturer that used embedded ARM
> >cores, and we also had problems with our earlier reference design
> >circuit boards debugging from RESET. The ARM7TDMI can be debugged
> >directly from reset, but it does take a correct circuit board and JTAG
> >pod design to do it since JTAG has to come out of RESET before ARM
> >comes out of reset accord to AN31. After we reworked our reference
> >design circuit board hardware, we were able to debug software out of
> >reset.  That was a really critical necessity at the time, since we had
> >some write once registers for system configuration that needed to be
> >written to very early in the normal boot sequence. If they were
> >written before the debugger got control, it was too late to debug any
> >difficulties related to that part of the system configuration.
> >  
> >
> I know that other ARM devices/boards can be debugged from reset, we
have 
> quite a few of them. Perhaps the LPC2xxxx boards we have (made by 
> theARMPatch, IAR, Olimex, Keil and Nohau) have all got the reset wiring 
> wrong - but I doubt it.
> 
> Regards
> Michael
> 

Are you using the same JTAG debugger pod on the ARM devices/boards
that will debug out of RESET?  I have always been under the impression
that ARM does not give licensees a lot of latitude in altering the
functions of the cores they license, so it is dificult to imagine why
it does not work with Phillip's parts. 

FWIW, I have just started playing around with an Embest board and
JTAG, and it will not debug out of reset either.  According to the
schematic of the Embest board, they do not have the necessary logic
indicated in AN31, so should be impossible to debug out of RESET. 
 
It is fairly certain in any case, that reset debug hardware would
certainly not be included in the final application hardware. It costs
money and space and is only useful in the specific instance of
debugging out of RESET.   We only included it on the reference designs
and development hardware.  

What is it about Phillip's ARM7TDMI that cause you to "doubt" the
accuracy of their ARM implementation? It seems much more likely that
the required external circuitry was simply not provided, since it is
*almost* never needed.

--Dave

Re: [lpc2000] Re: destroyed LPC2138 via software

2005-10-25 by Michael Johnson

derbaier wrote:

>--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
>  
>
>>>ARM Application Note 31 talks about debugging directly from RESET, so
>>>it *can* be done. I am just getting started using Phillip's products,
>>>but I used to work for a chip manufacturer that used embedded ARM
>>>cores, and we also had problems with our earlier reference design
>>>circuit boards debugging from RESET. The ARM7TDMI can be debugged
>>>directly from reset, but it does take a correct circuit board and JTAG
>>>pod design to do it since JTAG has to come out of RESET before ARM
>>>comes out of reset accord to AN31. After we reworked our reference
>>>design circuit board hardware, we were able to debug software out of
>>>reset.  That was a really critical necessity at the time, since we had
>>>some write once registers for system configuration that needed to be
>>>written to very early in the normal boot sequence. If they were
>>>written before the debugger got control, it was too late to debug any
>>>difficulties related to that part of the system configuration.
>>> 
>>>
>>>      
>>>
>>I know that other ARM devices/boards can be debugged from reset, we
>>    
>>
>have 
>  
>
>>quite a few of them. Perhaps the LPC2xxxx boards we have (made by 
>>theARMPatch, IAR, Olimex, Keil and Nohau) have all got the reset wiring 
>>wrong - but I doubt it.
>>
>>Regards
>>Michael
>>
>>    
>>
>
>Are you using the same JTAG debugger pod on the ARM devices/boards
>that will debug out of RESET?  I have always been under the impression
>that ARM does not give licensees a lot of latitude in altering the
>functions of the cores they license, so it is dificult to imagine why
>it does not work with Phillip's parts. 
>  
>
Yes.

>FWIW, I have just started playing around with an Embest board and
>JTAG, and it will not debug out of reset either.  According to the
>schematic of the Embest board, they do not have the necessary logic
>indicated in AN31, so should be impossible to debug out of RESET. 
> 
>It is fairly certain in any case, that reset debug hardware would
>certainly not be included in the final application hardware. It costs
>money and space and is only useful in the specific instance of
>debugging out of RESET.   We only included it on the reference designs
>and development hardware.  
>
>What is it about Phillip's ARM7TDMI that cause you to "doubt" the
>accuracy of their ARM implementation? It seems much more likely that
>the required external circuitry was simply not provided, since it is
>*almost* never needed.
>
>Mostly the fact that we don't have any boards that work correctly. I would have expected one of the board vendors to get it right - the information from ARM is clear. I can also see that having code that runs from reset (with debugging disabled) before the user application code enables a silicon vendor to create many product variants.
>  
>
Regards
Michael
Show quoted textHide quoted text
>--Dave
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-25 by philips_apps

The Philips ARM7 implementation can not be debugged through Reset for 
a very simple reason, it is called code security.

At reset, all debug channels are disabled to ensure that nobody can 
break into the chip. Then the code security memory cells are 
evaluated. If security is not desired by the programmer, the debug 
options are enabled. 

If Debug options would not be disabled in the beginning, there would 
be a time window that can be used to force entry into the device. 

ARM7TDMI, the core itself could be debugged from reset, correct but we 
prefer a higher security over minor restriction for debugging. 

Robert

Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-25 by derbaier

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
>
> The Philips ARM7 implementation can not be debugged through Reset for 
> a very simple reason, it is called code security.
> 
> 

Good enough reason!  :-)

If it is not too much trouble, I am curious why the code security
decision was not done using clock cycles between the release of the
external reset, and the release of the ARM core reset? That would just
look like XXX number of clock cycles between the release of external
reset and the very first memory fetch?  That would not cripple honest
debugging of non-secured code, and would still allow code security
wouldn't it?

Anyway, as you say, the inability to debug out of reset is something
that many people would never even notice, so it is probably no big deal.  

Thanks for the info!!!

--Dave
Show quoted textHide quoted text
> 
> ARM7TDMI, the core itself could be debugged from reset, correct but we 
> prefer a higher security over minor restriction for debugging. 
> 
> Robert
>

RE: [lpc2000] Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-25 by Paul Curtis

Robert, 

> The Philips ARM7 implementation can not be debugged through 
> Reset for a very simple reason, it is called code security.
> 
> At reset, all debug channels are disabled to ensure that 
> nobody can break into the chip. Then the code security memory 
> cells are evaluated. If security is not desired by the 
> programmer, the debug options are enabled. 
> 
> If Debug options would not be disabled in the beginning, 
> there would be a time window that can be used to force entry 
> into the device. 
> 
> ARM7TDMI, the core itself could be debugged from reset, 
> correct but we prefer a higher security over minor 
> restriction for debugging. 

Surely programming a fuse in the device would be enough to enable
security as found in so many other micros?  The MSP430 is insecure until
its fuse is blown.  The AVR can be similarly kneecapped.  There are
other ways to achieve the same level of security, one would assume.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

RE: [lpc2000] destroyed LPC2138 via software

2005-10-26 by Bruce Paterson

> The LPC2000 chips don't support debug from reset (or at least 
> we've never seen one that can). By the time that a debugger 
> has got control, the chip will have executed many 
> instructions - including ones that could turn off the JTAG 
> port, abort, turn on interrupts etc. There are a couple of 
> workarounds to this
> 
> - Use the serial port bootloader to erase the flash before 
> each debug session.

You can also use your application to erase just the first sector. This
has the effect of gromping on the interrupt vector table and checksum,
and leaving you in the bootloader after reset. I use this as a method of
forcing you into the standard bootloader in order to perform upgrades.
Of course, this needs your application to be able to run, and if it were
able to run ok you wouldn't need to debug from reset (since you can just
do a normal reset once the debugger has attached).....

>   - putting an invalid checksum in the interrupt vectors

Cheers,
Bruce

Re: [lpc2000] Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-26 by Michael Johnson

It would be useful to put words of this form somewhere into the user manual.

Thanks for the clarification.
Michael
Show quoted textHide quoted text
>The Philips ARM7 implementation can not be debugged through Reset for 
>a very simple reason, it is called code security.
>
>At reset, all debug channels are disabled to ensure that nobody can 
>break into the chip. Then the code security memory cells are 
>evaluated. If security is not desired by the programmer, the debug 
>options are enabled. 
>
>If Debug options would not be disabled in the beginning, there would 
>be a time window that can be used to force entry into the device. 
>
>ARM7TDMI, the core itself could be debugged from reset, correct but we 
>prefer a higher security over minor restriction for debugging. 
>
>Robert
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Re: [lpc2000] Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-26 by Michael Johnson

derbaier wrote:

>--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
>  
>
>>The Philips ARM7 implementation can not be debugged through Reset for 
>>a very simple reason, it is called code security.
>>
>>
>>    
>>
>
>Good enough reason!  :-)
>
>If it is not too much trouble, I am curious why the code security
>decision was not done using clock cycles between the release of the
>external reset, and the release of the ARM core reset? That would just
>look like XXX number of clock cycles between the release of external
>reset and the very first memory fetch?  That would not cripple honest
>debugging of non-secured code, and would still allow code security
>wouldn't it?
>
>Anyway, as you say, the inability to debug out of reset is something
>that many people would never even notice, so it is probably no big deal.  
>  
>
It is a big deal - if you are using a debugger you expect it to work 
from a stable starting point. Anyway at least the LPC2xxx parts have the 
P0.14 bootloader option - more than can be said for other ARM 
boards/chips we support.

Michael
Show quoted textHide quoted text
>Thanks for the info!!!
>
>--Dave
>
>
>  
>
>>ARM7TDMI, the core itself could be debugged from reset, correct but we 
>>prefer a higher security over minor restriction for debugging. 
>>
>>Robert
>>
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-26 by Guillermo Prandi

I'm sure I've read somewhere in Philips' documentation these days 
that you should use a delay loop in your startup code to be able to 
use JTAG debugging from the beginning of your program in order to 
avoid this kind of situation. Only I can't find where did I read that.

Guille

--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
>
> It would be useful to put words of this form somewhere into the 
user manual.
> 
> Thanks for the clarification.
> Michael
> 
> >The Philips ARM7 implementation can not be debugged through Reset 
for 
> >a very simple reason, it is called code security.
> >
> >At reset, all debug channels are disabled to ensure that nobody 
can 
> >break into the chip. Then the code security memory cells are 
> >evaluated. If security is not desired by the programmer, the debug 
> >options are enabled. 
> >
> >If Debug options would not be disabled in the beginning, there 
would 
> >be a time window that can be used to force entry into the device. 
> >
> >ARM7TDMI, the core itself could be debugged from reset, correct 
but we 
Show quoted textHide quoted text
> >prefer a higher security over minor restriction for debugging. 
> >
> >Robert
> >
> >
> >
> >
> >
> >
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >  
> >
>

Re: [lpc2000] Debugging from Reset (was Re: destroyed LPC2138 via software)

2005-10-26 by Michael Rubitschka

Hi

> >If it is not too much trouble, I am curious why the code security
> >decision was not done using clock cycles between the release of the
> >external reset, and the release of the ARM core reset?

I am no chip designer, but security often deserves a conservative approach,
to get sure there are no security holes left over for the thief,....

Cheers
Michael

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.