Forums

Debugging from flash

Started by timothymarknorton October 27, 2005
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?



An Engineer's Guide to the LPC2100 Series

> 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@lpc2..., "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@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