Lpc2000

We've just started making the move to Philips ARM7 (LPC213x).  I have 
a IAR Kickstart kit and starting my first project with the 32K limit 
compiler.  We've been toying with the idea of using the GNU compiler.  
However, from what I've found so far, it looks as though none of the 
free tools allow you to program and debug from flash.  Is this correct 
or am I missing something?

> We've just started making the move to Philips ARM7 (LPC213x).  I have
> a IAR Kickstart kit and starting my first project with the 32K limit
> compiler.  We've been toying with the idea of using the GNU compiler.
> However, from what I've found so far, it looks as though none of the
> free tools allow you to program and debug from flash.  Is this correct
> or am I missing something?

Take a look at the Phillips LPC213x example:
[default install]
C:\Program Files\IAR Systems\Embedded Workbench 4.0 
Kickstart\arm\src\examples\Philips\LPC213x\IAR-P213x\Lpc213x_demo.eww

The J-Link is setup as the debugger driver for this project and is ready to 
go.  Connect your J-Link to your target, make sure all is powered on 
correctly, and click debug.  It will load part and break on main().

The 32k Free tool covers most projects.  When you start hitting the wall 
switch to thumb mode, then start optimizing.  I'm currently running Segger's 
embOS RTOS, a SD FAT-16 implementation, six interrupt driven proprietary 
comm lines, fourteen I/O, and an RS-232 interface well within the 32k 
window.  Once I add the USB code I will most likely exceed the 32k CODE/DATA 
window.  The LPC2148 is a really nice part.  Nice work Phillips.


Joel

--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote:

> > However, from what I've found so far, it looks as though none of the
> > free tools allow you to program and debug from flash.  Is this correct
> > or am I missing something?

If you're going to use it on the job you should stick with
professional tools.

But, if you're looking at a hobby interest, or just a gig on the side,
then there are some free options:

http://www.olimex.com/dev/pdf/ARM%20Cross%20Development%20with%20Eclipse%20version%202.pdf

timothymarknorton wrote:

> We've just started making the move to Philips ARM7 (LPC213x).  I have
> a IAR Kickstart kit and starting my first project with the 32K limit
> compiler.  We've been toying with the idea of using the GNU compiler. 
> However, from what I've found so far, it looks as though none of the
> free tools allow you to program and debug from flash.  Is this correct
> or am I missing something?

You need to use hardware breakpoints in order to be able to debug code 
in Flash.
The ARM 7 TDMI (other ARM versions also) have 2 HW breakpoints.
Most debuggers use the HW breakpoints for specific purposes (interrupts 
& single stepping) and need SW breakpoints for other debugging purposes.

If you have the interrupt vectors in RAM, this may be handled by SW 
breakpoints - this frees one HW breakpoint for debugging purposes.

Some debuggers (or even most) will heve the ability to do this.
GDB has the option RDIROMATZERO, if you set this to 0 (set 
rdiromatzero=0) you get one HW breakpoint freed for debugging from Flash.

Regards,

    Rob

At 02:30 AM 10/28/05 +0000, timothymarknorton wrote:
>We've just started making the move to Philips ARM7 (LPC213x).  I have
>a IAR Kickstart kit and starting my first project with the 32K limit
>compiler.  We've been toying with the idea of using the GNU compiler.
>However, from what I've found so far, it looks as though none of the
>free tools allow you to program and debug from flash.  Is this correct
>or am I missing something?

Not true, or at least incomplete.

There is certainly plenty of free support for programming flash.  There is 
Philips own utility and two others that I am aware of for programming the 
flash via the serial port.  And IAP works whether you use GNU or a 
commercial compiler.

As far as debugging goes, it is quite possible to debug GNU code from flash 
either using commercial debuggers or even a wiggler.  The problem with 
using the wiggler for this is at the moment the higher level views don't 
support the use of the HW breakpoints so you can't single step or set 
breakpoints from Insights C source window.  You can use the assembly view 
to do so though.  It's also rather slow.

What I haven't seen in any of the descriptions of ANY available debugger 
for the ARM microcontrollers is one with a decent watchpoint facility.  One 
that would allow you to set a break when a certain value was written to a 
certain location or range of locations for instance (while running at full 
speed of course).

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Remember I'm a newbie to this.  I didn't digest all
that you said.  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.  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?

--- Rob Jansen <rob@...> wrote:

> timothymarknorton wrote:
> 
> > We've just started making the move to Philips ARM7
> (LPC213x).  I have
> > a IAR Kickstart kit and starting my first project
> with the 32K limit
> > compiler.  We've been toying with the idea of
> using the GNU compiler. 
> > However, from what I've found so far, it looks as
> though none of the
> > free tools allow you to program and debug from
> flash.  Is this correct
> > or am I missing something?
> 
> You need to use hardware breakpoints in order to be
> able to debug code 
> in Flash.
> The ARM 7 TDMI (other ARM versions also) have 2 HW
> breakpoints.
> Most debuggers use the HW breakpoints for specific
> purposes (interrupts 
> & single stepping) and need SW breakpoints for other
> debugging purposes.
> 
> If you have the interrupt vectors in RAM, this may
> be handled by SW 
> breakpoints - this frees one HW breakpoint for
> debugging purposes.
> 
> Some debuggers (or even most) will heve the ability
> to do this.
> GDB has the option RDIROMATZERO, if you set this to
> 0 (set 
> rdiromatzero=0) you get one HW breakpoint freed for
> debugging from Flash.
> 
> Regards,
> 
>     Rob
> 
> 



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

> Remember I'm a newbie to this.  I didn't digest all
> that you said.  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.  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?

Did you get the complete Kick Start setup with j-link?  If not you can use a 
Wiggler or Wiggler clone to debug with C-Spy.  I suggest you use at least a 
j-link.  lpctools.com has a good price on these.

The LPC parts have a MEMMAP register.  This determines where the interrupt 
vectors are mapped.  When debugging out of RAM the MEMMAP register is set to 
User RAM Mode.  The setup for this is done via a debugger macro file.

If the sum of you CODE/DATA and stack allocation exceed the size of the RAM, 
you have no choice but to debug out of Flash.  This is why it is advisable 
to use the part in your selected series with the most RAM.  When you debug 
with Flash the part is automatically programmed when C-Spy starts.  So when 
using JTAG there is no need for the serial boot loader.  The serial boot 
loader might be handy for field updates.

Joel

timothymarknorton wrote:

>We've just started making the move to Philips ARM7 (LPC213x).  I have 
>a IAR Kickstart kit and starting my first project with the 32K limit 
>compiler.  We've been toying with the idea of using the GNU compiler.  
>However, from what I've found so far, it looks as though none of the 
>free tools allow you to program and debug from flash.  Is this correct 
>or am I missing something?
>
>  
>
With my project, I have an LPC2106 and LPC2138 on the board.  I went 
with the GNU gcc toolchain running under Linux as the developement 
platform.  Debug is done with Insight-6.1 (patched for register bug) and 
an Abatron BDI2000.  I can debug from Flash as the Insight talks with 
the BDI2000 and they seem to get on well together.

For programming, having set my config file with the binary name to be 
used, I simply open a telnet window to the BDI2000.  From there, I type 
"erase" and then "prog" to put a new program into Flash.  I then reload 
the symbols from Insight: "Run | Disconnect", "File | <most recent>", 
"Run | Connect" and start working with the new program.

The BDI2000 is pricey, compared with the wigglers, but, I don't have to 
worry about if the 0.1uf caps should be on the Wiggler lines, or if my 
wires are too long...


TomW

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

> What I haven't seen in any of the descriptions of ANY available
debugger 
> for the ARM microcontrollers is one with a decent watchpoint
facility.  One 
> that would allow you to set a break when a certain value was written
to a 
> certain location or range of locations for instance (while running
at full 
> speed of course).

I can only think of 2 ways to implement flexible conditional breakpoints:

1) set an undconditional breakpoint "behind the scenes". and when it
breaks, the PC will request data on memory contents and the PC decides
if it will break for the user, or if it will reset the breakpoint and
continue execution. This is slow, but easy to implement.

2) the highest performance is done by downloading some extra assembler
code to the ARM. Set an unconditional breakpoint, and when it breaks
the ARM assembly code will evaluate the condition, and decide what to
do. This is almost full speed, but it's harder to implement.

Eric

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

At 04:48 AM 10/29/05 +0000, Eric Engler wrote:
> > What I haven't seen in any of the descriptions of ANY available
>debugger
> > for the ARM microcontrollers is one with a decent watchpoint
>facility.  One
> > that would allow you to set a break when a certain value was written
>to a
> > certain location or range of locations for instance (while running
>at full
> > speed of course).
>
>I can only think of 2 ways to implement flexible conditional breakpoints:
>
>1) set an undconditional breakpoint "behind the scenes". and when it
>breaks, the PC will request data on memory contents and the PC decides
>if it will break for the user, or if it will reset the breakpoint and
>continue execution. This is slow, but easy to implement.
>
>2) the highest performance is done by downloading some extra assembler
>code to the ARM. Set an unconditional breakpoint, and when it breaks
>the ARM assembly code will evaluate the condition, and decide what to
>do. This is almost full speed, but it's harder to implement.

Neither of those will provide a data watchpoint though which is what I was 
referring to above.  Since in order to implement that you would have to 
single step through the code at the instruction level and evaluate at every 
step.  This would be considerably below full speed.  I suspect that this is 
only possible with a proper ICE and I haven't seen one of those for any 
micro that has a BDM or JTAG interface.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Robert Adsett wrote:

>  Neither of those will provide a data watchpoint though which is what I
> was
>  referring to above.  Since in order to implement that you would have to
>  single step through the code at the instruction level and evaluate at
> every
>  step.  This would be considerably below full speed.  I suspect that this
> is
>  only possible with a proper ICE and I haven't seen one of those for any
>  micro that has a BDM or JTAG interface.

And the ARM7 has a proper ICE.
See my previous post http://groups.yahoo.com/group/lpc2000/message/9851
which explains the function of the ARM Embedded ICE module.

A breakpoint is just a watchpoint that breaks on address + instruction
fetch. A watchpoint breaks on address + data read/write, possibly with a
specific data pattern.

This means that the ARM can use a hardware watchpoint while running at
system speed. I have used this using the ARM RealView tools.

I am not sure of other debuggers though.

Rob

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:

> What I haven't seen in any of the descriptions of ANY available
debugger 
> for the ARM microcontrollers is one with a decent watchpoint
facility.  One 
> that would allow you to set a break when a certain value was written
to a 
> certain location or range of locations for instance (while running
at full 
> speed of course).
> 
> Robert
>

I am using Ashling PathFinder and Opella. I can "set a break when a
certain value was written to a certain location or range of locations".

At 05:14 AM 10/30/05 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> > What I haven't seen in any of the descriptions of ANY available
>debugger
> > for the ARM microcontrollers is one with a decent watchpoint
>facility.  One
> > that would allow you to set a break when a certain value was written
>to a
> > certain location or range of locations for instance (while running
>at full
> > speed of course).
> >
> > Robert
> >
>
>I am using Ashling PathFinder and Opella. I can "set a break when a
>certain value was written to a certain location or range of locations".


Nice, I hadn't noticed that when I last looked at their literature.  Not a 
feature you need often but when you do there isn't anything that will 
substitute for it.

With that an the ETM you appear to have almost a full ICE capability. I 
think the biggest thing left is probably the quantity of breakpoint and 
watchpoints.   And if other vendors follow Seggers example then that will 
just leave the quantity of data watchpoints which is often low in a 'real' 
ice anyway.

My thanks to you and Rob for correcting my oversight.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/