Setting multiple breakpoints and a program trace on MCF5216 V2 core?!

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Setting multiple breakpoints and a program trace on MCF5216 V2 core?!

Jump to solution
797 Views
DaveTonyCook
Contributor IV

From the description taken from the product brief shown below and the documentation provided with CodeWarrior 6.4 it should be possible to set more than 1 breakpoint. In fact I would have thought it to be a pre-requisite. However when I try to set a 2nd BP an error message tells me that I have possibly reached my hardware breakpoint limit.  Is this correct?

 

Also whilst the documentation (CW & Hardware REF) tell me program trace is possible I am confounded as to how one might go about it.

 

Any help would be greatly received. Thanks

 

MCF5216 Integrated Microcontroller Product Brief [Document Number: MCF5216PB Rev. 1, 08/2006]

 

 

 

1.2.3 Debug Module

The ColdFire processor core debug interface is provided to support system debugging in conjunction with

low-cost debug and emulator development tools. Through a standard debug interface, users can access

real-time trace and debug information. This allows the processor and system to be debugged at full speed

without the need for costly in-circuit emulators.The debug interface is a superset of the BDM interface

provided on Freescale’s 683xx family of parts.

 

The on-chip breakpoint resources include a total of 6 programmable registers—a set of address registers

(with two 32-bit registers), a set of data registers (with a 32-bit data register plus a 32-bit data mask

register), and one 32-bit PC register plus a 32-bit PC mask register. These registers can be accessed through

the dedicated debug serial communication channel or from the processor’s supervisor mode programming

model. The breakpoint registers can be configured to generate triggers by combining the address, data, and

PC conditions in a variety of single or dual-level definitions. The trigger event can be programmed to

generate a processor halt or initiate a debug interrupt exception.

To support program trace, the Version 2 debug module provides processor status (PST[3:0]) and debug

data (DDATA[3:0]) ports. These buses and the PSTCLK output provide execution status, captured operand

data, and branch target addresses defining processor activity at the CPU’s clock rate.

 

Labels (1)
0 Kudos
1 Solution
436 Views
TomE
Specialist II

> when I try to set a 2nd BP an error message tells me that I have possibly

> reached my hardware breakpoint limit.  Is this correct?

Yes. That hardware supports one and one only HARDWARE breakpoint.

I typed in an explanation, but then searched these forums for "hardware breakpoints" and found this great explanation as the first hit:

Software and hardware breakpoints

When your code is in RAM you can have as many breakpoints as you like as the debugger replaces target instructions with "breakpoint" ones. When the code is in ROM you're restricted to the number of hardware breakpoints.

Other CPU families can support 2 or 4 hardware breakpoints, but not this one.

If having more than one hardware breakpoint is important to you then choose a different CPU. Apparently the ARM-core ones have four hardware breakpoints.


I've worked with one CPU that actually rewrote the entire FLASH in order to write and replace the breakpoint instructions. It was horribly slow, but it worked.

These restrictions (and any workarounds) should be in the CW documentation somewhere.


Tom

View solution in original post

0 Kudos
3 Replies
437 Views
TomE
Specialist II

> when I try to set a 2nd BP an error message tells me that I have possibly

> reached my hardware breakpoint limit.  Is this correct?

Yes. That hardware supports one and one only HARDWARE breakpoint.

I typed in an explanation, but then searched these forums for "hardware breakpoints" and found this great explanation as the first hit:

Software and hardware breakpoints

When your code is in RAM you can have as many breakpoints as you like as the debugger replaces target instructions with "breakpoint" ones. When the code is in ROM you're restricted to the number of hardware breakpoints.

Other CPU families can support 2 or 4 hardware breakpoints, but not this one.

If having more than one hardware breakpoint is important to you then choose a different CPU. Apparently the ARM-core ones have four hardware breakpoints.


I've worked with one CPU that actually rewrote the entire FLASH in order to write and replace the breakpoint instructions. It was horribly slow, but it worked.

These restrictions (and any workarounds) should be in the CW documentation somewhere.


Tom

0 Kudos
436 Views
DaveTonyCook
Contributor IV

Hi Tom,

Thanks again your answer pointed me to the right place.  I've had a search for an explanation on how to use the Trace Collection facility however I cant find anything. The documentation that comes with the CodeWarrior 6.4 suggests that Trace Collection can be switched on with the command:

    1. Click Debug > Set Eventpoint > Set Trace Collection Off.

This option is not visible in the IDE ??

Lifes a B

Why are the docs sooooo misleading. below is an extract from the MCF5216 product brief:

• System debug support

— Real time trace for determining dynamic execution path

— Background debug mode (BDM) for in-circuit debugging

— Real time debug support, with two user-visible hardware breakpoint registers (PC and address

with optional data) that can be configured into a 1- or 2-level trigger

0 Kudos
436 Views
TomE
Specialist II

> Lifes a B

Debug support has gone through a number of "generations". Try in-circuit debugging on an MC68302 sometime. Or an ST72 series. You had to buy a $300 "socket adaptor" to solder to your board and then plug a CPU Emulator into that socket. That was the technology in 1989.

The BDM built into the CPU was a great advance, which came in during the 1990's. The smaller CPUs have simple ones (with one hardware breakpoint) whereas the more expensive ones like the 1995 MPC860 had four. Newer generations of chips allocate even more silicon and give you more features, such as more breakpoints, multi-level triggers, on-CPU trace storage and so on. But  by using the MCF5216 you're using very early generation debugging, dating from at least 1995 if not earlier. If you want modern features you have to buy a more modern chip than something designed 20 years ago.

The MCF5485 Reference manual details the evolution of the ColdFire Debug modules in section 3.2.2, The MCF52xx has Debug Module Revision A. Some  MCF53xx ones have Revision B Others have "Revision B+" which has 4 PC Breakpoints, as does the MCF5485 with Revision C.

> suggests that Trace Collection can be switched on with the command:

It can, as long as you've shelled out the money for a high-capability debug pod that supports capturing the real-time trace. Like this one:

P&E Microcomputer Systems - Tracelink - Development interface (USB, Ethernet) featuring Exte...

The "USB Multilink Universal" cost $119. The one that supports Real Time Trace costs US$999. That's not that much after you've paid for Code Warrior, especially if you can share one of those pods between multiple developers..

There are different trace capabilities. Some chips have PSTn and DATn signals, whereas others don't.

> Background debug mode (BDM) for in-circuit debugging

It does that.

> Real time debug support, with two user-visible hardware breakpoint registers (PC and address with optional data)

Which only lets you set one breakpoint in ROM. The MCF5329 supports 4 hardware breakpointsThe "K20 Family Product Brief" details a far more powerful debug unit, with "four comparators" configurable all sorts of ways, and lots of other features.

Tom