Lpc2000

Hi David

The board holds the DBGSEL down - this isn't under software control via
a wiggler. With the other ARM systems we have we can program the ICE
breaker registers whilst keeping the CPU in reset - when we release
reset the CPU hits a breakpoint. So the CrossWorks reset for an
Evaluator7T looks like this

function Evaluator7T_Reset()
{
  TargetInterface.setNSRST(0);
  TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0xFFFFFFFF,
0x00000000, 0xFFFFFFFF, 0x100, 0xF7);
  TargetInterface.setNSRST(1);
  TargetInterface.waitForDebugState(1000);
  TargetInterface.trst();
}

and the reset for the LPC2100 looks like this

function LPC210X_Reset()
{
  TargetInterface.setNSRST(0);
  TargetInterface.setNSRST(1);
  TargetInterface.delay(100);
  TargetInterface.trst();
  TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0xFFFFFFFF,
0x00000000, 0xFFFFFFFF, 0x100, 0xF7);
  TargetInterface.waitForDebugState(1000);
}

Given the fact that two pins are used to select the debug mode (DGBSEL
and RTCK) it would have been nice to be able to select JTAG debug
without ETM (the main pin user).

I don't think we knew about the differences in the Debug comms register
for this chip thanks for the pointer. If we are at the maximum flashing
speed then there is little to be gained to increasing the Debug comms
performance for us.

Regards
Michael

> 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