Yahoo Groups archive

Lpc2000

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

Message

Re: [lpc2000] Debugging from flash

2005-10-29 by Rob Jansen

Mark Norton wrote:

> Remember I'm a newbie to this.  I didn't digest all
> that you said.

That's the good thing on this mailinglist, there will always be persons 
willing to help out :-)

>   From what you wrote I gather that I
> can use JTAG debugging and have the program run from
> flash with a totally free set of tools.  I gather that
> I must program the code using the Philips flash
> utility.  

Indeed, the code must first be programmed in Flash. This can be done 
with a serial programming tool like the Philips tool of lpc21isp but a 
number of tool sets will allow the programming of flash via jtag.

> Then I would be able to debug.  If I need to
> use break points, then I need to run part of the code
> from flash and have the interrupt vectors in RAM.
> This would allow me 1 break point.  Did I get this
> right?

Yes, at least that is what I was able to do with GDB combined with a 
Jeeni (on an ARM7 TDMI).
The same principle should apply for the ARM7 TDMI-S (the variant used in 
the lpc21xx series) and other jtag debuggers.
Some toolsuites will give you the ability to distinguish between hard- 
and software breakpoints yourself (the ARM RealView Developer Suite - 
RVDS 2.1 - that I currently use provides this).
Other toolsuites will decide themselves when soft- or hardware 
breakpoints are used.

Some background information:

The lpc21xx (and other ARM7 TDMI/TDMI-S processors) include the Embedded 
ICE module. This module gives the ability to debug your target by 
providing some nice functionality:

1) There are two hardware watchpoints (or breakpoints). Each HW 
watchpoint is controlled by a set of registers in the Embedded ICE 
module where you may specify address and data values and masks and also 
specify if this watchpoint is valid for data read/write or instruction 
fetch.
   Using such a watchpoint allows you to place a breakpoint on one 
address (or an address range) in your code but it can also be used as a 
watchpoint (read and/or write an address or a range of addresses with 
possible even a specific data pattern).
   Most development tools will only give you limited access to the 
possibilities of these registers.
2) There is a Debug Communication Channel (DCC) that allows 
communication from debugger software with target software. It's like a 
32 bits wide UART and some debuggers indeed provide a terminal console 
via this channel. It's use seems almost unlimited, OS aware debugging 
and a PPP connection can also be setup via DCC (if you have/write the 
software for this).
3) It is possible to detach the CPU core from the memory system. In this 
way instructions can be fed directly into the processor so that 
registers can be read or written. By switching this on and of during 
debug it is also possible to read/write memory and run your program.

Jtag debuggers use one HW breakpoint to implement SW breakpoints (break 
on the instruction fetch of one specific -invalid- instruction) during 
program execution (run mode). It is used as single step breakpoint 
during single step mode (break on any instruction fetch).
Catching interrupts uses the second HW breakpoint (break on instruction 
fetch in the interrupt vector area) leaving no hardware breakpoint free 
for placing a hardware breakpoint in your flash program.

If the interrupt vectors are in RAM, the second HW breakpoint can be 
freed by using SW breakpoints on the interrupt vectors. This then gives 
the ability to have 1 HW breakpoint for your code in Flash.

All this depends a bit on the debugger used. Some debuggers will catch 
interrupts by default but will allow you to turn this on or off (for 
specific interrupts) - this allows you to implement e.g. your own 
data/instruction-prefetch abort or invalid instruction handler or to use 
the debuggers default error handling. Using a HW breakpoint you only get 
1 watchpoint but debuggers may catch a wider area of memory to track 
more than one watchpoints in one go - this may however impact program 
execution.

You may find detailed information on the Embedded ICE module in the ARm 
7 TDMI-S Technical Reference Manual (DDI0234A on the ARM website). 
Section 5 contains detailed information on debugging,  5.6 holds a small 
description on the Embedded ICE, 5.10 shows DCC and 5.20 ~ 5.22 contains 
a detailed explanation on the watchpoint registers - this is good 
background information to read if you like to know what happens while 
debugging and it gives some insight information on the limitations of 
debugging the ARM7.

Regards,

Rob

Attachments

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.