EmbeddedRelated.com
Forums
Memfault State of IoT Report

New IAR debugging probe

Started by Leon Heller May 21, 2012
On Tue, 2012-05-22 at 09:14 +0100, Paul Curtis wrote:
> IAR acquired Signum Systems, as was stated in this thread;

That is why there is no response to my emails from them
about my jtagjet-tms for the tms320f2808 processor we are
using. They promised the linux drivers for CCS about
2 years ago, to be released that year in september.
Anyway we are back to using a ftdi based debugger
(xds100) now instead of this rather expensive signum
product :-(

roelof

An Engineer's Guide to the LPC2100 Series

--- In l..., "roelof 't Hooft" wrote:
>
> On Tue, 2012-05-22 at 09:14 +0100, Paul Curtis wrote:
> > IAR acquired Signum Systems, as was stated in this thread;
>
> That is why there is no response to my emails from them
> about my jtagjet-tms for the tms320f2808 processor we are
> using. They promised the linux drivers for CCS about
> 2 years ago, to be released that year in september.
> Anyway we are back to using a ftdi based debugger
> (xds100) now instead of this rather expensive signum
> product :-(
>
> roelof
>

I would love to hear about how well this xds100 debugger is working !

boB

Paul,

out of curiosity, who else is offering Flash Breakpoints besides Segger? AFAIK, U-Link does not offer this, all the OCDxyz and other low cost do not offer this either!?
What did I miss?
It took Segger lots of effort to optimize flash breakpoints and these breakpoints can be set really fast, work very well ...
Just interested what alternatives there might be, currently I have no desire to switch.

Bob

--- In l..., "Paul Curtis" wrote:
>
> Hi,
>
> > J-link... guess I've been lucky? WIndows 7, windows XP, ARM7, never had
> > any issues. The IAR debugger with flash breakpoints is great. If someone
> > took away my flash breakpoints tool, I'd go after them with an axe!
>
> Flash breakpoints are available with any JTAG debugger, with the right
> software. Certainly, J-Link isn't the only kid on the block here.
>
-- snip --

On 23 May 2012, at 19:35, Bob T wrote:

> Paul,
>
> out of curiosity, who else is offering Flash Breakpoints besides Segger?

We are. On any JTAG adapter, including wigglers.

> AFAIK, U-Link does not offer this, all the OCDxyz and other low cost do not offer this either!?
> What did I miss?

You miss the engineering work required to do this outside of the adapter itself.

>
> It took Segger lots of effort to optimize flash breakpoints and these breakpoints can be set really fast, work very well ...
> Just interested what alternatives there might be, currently I have no desire to switch.
>

Then you're stuffed, metaphorically.

-- Paul.

uLink definitely does offer flash breakpoints, any good debugger should
since the HW support required for them is in the microcontroller core, it
does not need any HW in the jtag probe.

One criticism I have of uLink, and it would be interesting to know how
others handle this is the switch between HW and SW breakpoints.

SW BP's can only be used in RAM, so uLink defaults to HW breakpoints, but as
soon as you use more than the number supported by the core it switches
everything to SW BP's and no bp's every get hit.

It would be nice to be able to specify ONE BP that is always a HW BP.

The reason is that the BP's get installed by the debugger before the boot
code runs, so when running from flash and copying to RAM the BP's get
overwritten. What is needed is a HW BP to be set after the startup code has
been executed which can then be used to halt the CPU and let the debugger
install the SW BP's in RAM so that they don't get overwritten.

A workaround seems to be to put a memory access BP ( which is always in HW
) at a location that does not get written by the loader and then access this
from main, the debugger then restores the correct SW BP's.

Regards

Phil.

From: l... [mailto:l...] On Behalf Of
Bob T
Sent: 23 May 2012 19:36
To: l...
Subject: [lpc2000] Re: New IAR debugging probe

Paul,

out of curiosity, who else is offering Flash Breakpoints besides Segger?
AFAIK, U-Link does not offer this, all the OCDxyz and other low cost do not
offer this either!?
What did I miss?
It took Segger lots of effort to optimize flash breakpoints and these
breakpoints can be set really fast, work very well ...
Just interested what alternatives there might be, currently I have no desire
to switch.

Bob

--- In l... , "Paul
Curtis" wrote:
>
> Hi,
>
> > J-link... guess I've been lucky? WIndows 7, windows XP, ARM7, never had
> > any issues. The IAR debugger with flash breakpoints is great. If someone
> > took away my flash breakpoints tool, I'd go after them with an axe!
>
> Flash breakpoints are available with any JTAG debugger, with the right
> software. Certainly, J-Link isn't the only kid on the block here.
>
-- snip --



A wish I have for JTAG, flash breakpoints, etc., is maybe an NXP unique issue... there's no way I can find to disable or otherwise keep control of the CPU/Core, with JTAG plugged in, when the watchdog timer expires. It just blows-up the debugger and JTAG.

I'd wish that when JTAG is plugged in/active, the watchdog could be disabled as an option. Of course, there comes a time when you need to test the watchdog interrupt, but I tend to just let it reset the CPU.

My code is so perfect that the watchdog can never fire.

On Thu, May 24, 2012 at 1:22 PM, stevec wrote:

> A wish I have for JTAG, flash breakpoints, etc., is maybe an NXP unique
> issue... there's no way I can find to disable or otherwise keep control of
> the CPU/Core, with JTAG plugged in, when the watchdog timer expires. It
> just blows-up the debugger and JTAG.
>

this is a well known issue. use your jtag to disable the watchdog, or use
debug code that doesn't enable it when debugging


"use your jtag to disable the watchdog"
With J-Link and EWARM, I've found no way to do so. Is there a way?

To disable the watchdog timer, the only way I've found is to run code that does not enable the watchdog, but then I must cause it to timeout once.

PITA.

--- In l..., Triffid Hunter wrote:
>
> On Thu, May 24, 2012 at 1:22 PM, stevec wrote:
>
> > A wish I have for JTAG, flash breakpoints, etc., is maybe an NXP unique
> > issue... there's no way I can find to disable or otherwise keep control of
> > the CPU/Core, with JTAG plugged in, when the watchdog timer expires. It
> > just blows-up the debugger and JTAG.
> > this is a well known issue. use your jtag to disable the watchdog, or use
> debug code that doesn't enable it when debugging
>
>

On Thu, 24 May 2012 03:22:33 -0000, you wrote:

>A wish I have for JTAG, flash breakpoints, etc., is maybe an NXP unique issue... there's no way I can find to disable or otherwise keep control of the CPU/Core, with JTAG plugged in, when the watchdog timer expires. It just blows-up the debugger and JTAG.
>
>I'd wish that when JTAG is plugged in/active, the watchdog could be disabled as an option. Of course, there comes a time when you need to test the watchdog interrupt, but I tend to just let it reset the CPU.
>
>My code is so perfect that the watchdog can never fire.

On some of the NXP parts, e.g. LPC2136 using PINSEL2, it is possible for software to detect when
JTAG is being used, so the code can decide to not enable the watchdog at startup.
Hi,

> uLink definitely does offer flash breakpoints, any good debugger should
> since the HW support required for them is in the microcontroller core, it
> does not need any HW in the jtag probe.

You have the wrong end of the stick. The OP is asking whether any other
JTAG probe has the ability for the Segger Flash Breakpoint feature:

http://www.segger.com/jlink-flash-breakpoints.html

This allows unlimited breakpoints in flash memory and is absolutely not part
of the core. U-LINK doess not offer it.

http://www.keil.com/ulink/cmp.asp

For Flash Breakpoints you require intelligence in the JTAG adapter/host
software to manage flash reprogramming. The J-Link Flash Breakpoint feature
allows this, and CrossWorks can do this too on any JTAG adapter.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426


Memfault State of IoT Report