Why don't breakpoints work??

[Dogbert256]

-- Please Help --                 -- Please Help --                 -- Please Help -- 

Processor = MCF5232, using external Flash memory in debug mode for first time (had to configure LCF file to do this).  Using CodeWarriors V10.0.

When I was running code out of the internal SRAM of processor, there did not seem to be an issue with using breakpoints.  Now I'm running code out of external Flash memory.  Breakpoints that I set (blue dot) rarely actually happen.  VERY frustrating to debug like this.  I've tried breakpoints, hardware breakpoints, watchpoints, etc...  Nothing seems to work.

Is there a SIMPLE way to get the debugger to stop at a particular line of code while running out of external Flash memory?  Extensive reading through the CodeWarriors documentation suggests it can be done but following these instructions does not work (breakpoint rarely stops at the line of code).

Thx,

Dogbert

[TomE]

Start by searching for "breakpoint" in the Code Warrior forums.

Tom

[Dogbert256]

Looking through the forum, it looks like when running from external Flash, there is only one breakpoint available.  This would be consistent with the behavior I'm seeing.

So it appears as though the solution is to debug from the external SRAM, and only use external Flash for standalone operation (?).

Dogbert

[TomE]

> when running from external Flash, there is only one breakpoint available.

MCF5235 Reference Manual

Chapter 32 Debug Support

32.4.7 Program Counter Breakpoint/Mask Registers (PBR, PBMR)

The MCF5235 (includes MCF5232) has the "Revision A Debug Module". There is only *ONE* register pair in the "A Revision" that can match a single program counter value. Technically there's a "match" and a "mask" register, so you could match multiple addresses as long as they're within certain "binary clumps". I can't imagine any debugger being able to support that though.

One hardware breakpoint is essentially useless for debugging. It means you can't even set a breakpoint on both paths of a conditional branch. You might be able to set the breakpoint before the branch, then single-step over it (if the debugger supports single-stepping, some of them use the hardware breakpoints to do that).

The MPC860 I was using in the late 1990's (released in 1995) had four instruction breakpoints. So does every x86 from the 80386 onwards (1985).

The MCF5208 manual states:

26.1.2 Overview

The first version 2 ColdFire core devices implemented the original debug architecture, now called revision A. Based on feedback from customers and third-party developers, enhancements have been added tosucceeding generations of ColdFire cores. For revision A, CSR[HRL] is 0. See Section 26.3.2, “Configuration/Status Register (CSR)”.

Revision B (and B+) of the debug architecture offers more flexibility for configuring the hardware breakpoint trigger registers and removing the restrictions involving concurrent BDM processing while hardware breakpoint registers are active. Revision B+ adds three new PC breakpoint registers.

The later MCF52xx chips and the MCF5329 all have the debug module with four program counter breakpoint registers. Various ColdFire V1 chips have the "B" version of the debug module too.

The version of the Debug module should be an important part of the chip selection criteria.

Tom

[NNeff]

Hi Tom,

You say "One hardware breakpoint is essentially useless for debugging." -- yes indeed!  I'm finding this out the hard way.  The Kinetis chip we're using has only two hardware breakpoints available, and the step-over and step-into functions don't work if you have two breakpoints set, so there's functionally really only one.  I think we need to yell at Freescale to encourage them to put a reasonable number of hardware breakpoints in their debug modules for the Kinetis line.

[TomE]

> The Kinetis chip we're using has only two hardware breakpoints available,

I've just found your posts on this, you're using KE06.

Why are breakpoints not working, and how do I fix it?

The first manual I looked at (before finding you were using the KE06) was the K60 one. It doesn't have anything as simple as a table of features. The "ARM CoreSight" is very complicated. Searching for "breakpoint" finds the FPB can be used to patch out the Flash in a running system, or can be used to provide 6 hardware breakpoints. I don't know if the debugger knows how to use this facility. The word "breakpoint" doesn't appear anywhere else in the over 1800 pages. The DWT has Watchpoints and "tracing", but it isn't obvious if they can be used to breakpoint or single-step.

The K70 manual looks to be the same as the K60. I'd guess all the "K" series (Cortex M4) would be similar.

The Kinetis "L" Series  (Cortex M0+) "KL02 Sub-Family Reference Manual" has "Table 3-4. ARM Cortex-M0+ parameter settings" which details the options that Freescale has selected. They've selected "BKPT=2", which means only two breakpoints. The top chip in the "L" family (KL46 Sub-Family Reference Manual) has the same setting.

The manual says to go to arm.com for details on the core, and there we find:

Cortex-M0+ Processor - ARM

    Debug Optional JTAG or Serial-Wire Debug Ports Up to 4 Breakpoints and 2 Watchpoints

So four debugs are possible, but weren't optioned on that core.

The same table in the KEA series shows they selected "2" there as well. Ditto KE, KV and probably MK and KW as well.

This has all been covered in the Kinetis forums in your post there and in others like this one:

Re: Problem in more than 2 breakpoint use for MKE04Z128 series micro-controller.

> I think we need to yell at Freescale to encourage them to put a reasonable number of hardware breakpoints in their debug modules for the Kinetis line.

They can't use their tried and true ColdFire core debug technology in these chips, and they optioned only two breakpoints. These decisions were made years ago and are "set in silicon". As I said in a previous post on this thread:

> The version of the Debug module should be an important part of the chip selection criteria.

So if the number of breakpoints is important to you, then you should choose  a more capable chip like one of the M4 ones.

Or, as suggested in responses to your original post, if this is wasting time and money for you, buy a "Segger J-Link". It probably erases and reprograms the Flash every time you hit "run" or when it breakpoints. I've used other chips (without hardware breakpoints) that do that to allow debugging.

> the step-over and step-into functions don't work if you have two breakpoints set

You can EITHER use breakpoints or you can single-step. You can't do both. What you need is a friendly debugger with automation that disables the breakpoints when you're single-stepping, and puts them back when you hit "run". Or a scriptable debugger, like the one I was using on the MPC860 EIGHTEEN YEARS AGO in 1997 that let you write scripts to automate this sort of stuff. Do you have the "skipping breakpoints" button? That seems to be what it is for:

Skipping Breakpoints | MCU on Eclipse

Tom