Lpc2000

lpc2100_fan <lpc2000@yahoogroups.com> wrote:

> since your last post I learned something new about debugging. The
> Philips implementations of the ARM micros include something called
> Real-Time-Monitor, a ROM monitor that comes from ARM and will be

in the PDF document you mentioned, I only found the term 
"RealMonitor": "RealMonitor is a component of ADS, and requires 
either Multi-ICE Version 2.0 or ARM ADI". It "uses the target 
processor DCC channel" and needs "RMTarget" software running on the 
ARM7 (I guess using standard IRQ from DCC).

I found no spec about the CPU cycles needed to transfer one word from 
or to target memory - any hint where to look?

Anyway, that's _not_ like Motorola BDM, where unused bus cycles are 
used to access target memory. BDM is handled by a piece of hardware 
in the uC and doesn't require RAM, ROM or CPU cycles.

In (some of) my applications, I have code portions where the precise 
timing is essential (e.g. integrating an analog signal over a 2us 
period). If some debug firmware runs hundreds of nanoseconds or even 
longer, the device doesn't work as intended.

> (better) supported by an upcoming release of the ARM toolchain. As
> always, it is a matter of tool support but the firmware in the
> microncontroller exists to do background debugging similar or a little
> better than on the Motorola chips without using the Trace feature
> (which costs quite some extra pins but provides Code trace without ANY
> real-time conflicts). 

I don't see the advantage over the Motorola solution, maybe I missed 
something?

Can I read memory via ETM during program execution?

BTW: there is also a (small) trace buffer in newer HCS12 derivatives.

Oliver
-- 
Oliver Betz, Muenchen