Reply by Robert Adsett October 30, 20052005-10-30
At 05:14 AM 10/30/05 +0000, you wrote:
>--- In lpc2000@lpc2..., 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/


An Engineer's Guide to the LPC2100 Series

Reply by eser...@ October 29, 20052005-10-29
The PutQueue procedure uses a Count Type of Integer.
Arrays that start at 1 are treated differently than arrays that start with 0.
Manual says, "If the queue is full, PutQueue will suspend the task until there is enough room to insert the data."
Keep trying to fix it, and let us know what happens.

Eric
----- Original Message -----
From: wurlitzer28

Subject: [BasicX] BX24 Comm1 should send 3 bytes but only 2 received I have fought this for the last 2 days. This routine looks for a bit
or bits that have changed since the last time the program read a word
from PortA.



Reply by Rob Jansen October 29, 20052005-10-29
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


Reply by Robert Adsett October 29, 20052005-10-29
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/


Reply by Rob Jansen October 29, 20052005-10-29
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



Reply by Eric Engler October 29, 20052005-10-29
> 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



Reply by Tom Walsh October 28, 20052005-10-28
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..."
----------------


Reply by Joel Winarske October 28, 20052005-10-28
> 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


Reply by Mark Norton October 28, 20052005-10-28
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



Reply by Robert Adsett October 28, 20052005-10-28
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/