Lpc2000

> 1) the JTAG reset resets the TAP/ICE breaker registers. This makes
> starting under debug control potentially problematic - i.e. there is a
> window of opportunity after reset where the CPU can run before the
> debugger can get the chip under debug control. We have many other ARM
> chips/boards with odd reset behaviour so we put in a  JavaScript'able
> reset capability into CrossWorks that can control the reset the debugger
> does. For example the with ATMEL AT91 processors the watchdog can be
> used to reset the CPU. 

Are you holding DBGSEL down while resetting the chip with RST* when you
notice this?  Or am I misunderstanding you.

> 2) the debug comms port requires synchronisation i.e. the status bit has
> be tested to make debug comms work. I guess this is part of the spec but
> things can go a lot quicker without testing the status bit - i.e. hoping
> the ARM is faster than the host.

So the core is a ARM7TDMI-S rev 3 core and not a rev 4?  The document
DDI023A_7TDMIS_R4.pdf in section 1.5.2 covers the differences I'm thinking
of.

> 3) a lot of I/O pins are lost when you enable JTAG debugging.

He he he, with 48 pins to start with....  Too bad there isn't a way to
reassign them back to I/O after you start debugging and decide you
don't need them.

If Philips really loved us, they would assign the debug functions to 
the *new* pins when going from a lower pin count package to a higher--
that way the next chip up in the product line could be used as a
pin-loss-free debugger for the next guy down.  I can dream, right?

> I just did a quick test - CrossWorks can flash load an LPC2100 using a
> wiggler at 13Kbytes per second? I know that we can flash load an
> Evaluator7T at 18Kbytes per second. Can anyone comment on if we have hit
> the limit on flash programming performance on the LPC2100?

Until someone gets some nice ICP FLASH code going, probably not.

Cheers,
David