USB TAP is too slow

[ZiglioNZ]

CodeWarrior for Coldfire 7.1

Hi,

with the size of my project growing (850K Code, 433K Data), debugging with USB TAP is becoming increasingly painful.

I wonder if there are strategies for increasing its responsiveness, before looking for a much more expensive option.

- does the total number of breakpoints affect the time it takes from hitting a breakpoint to regaining control of the IDE?

- same with expressions, does having many expressions inpact the USB TAP responsiveness?

One thing I've found to help is disabling 'Show variable values in source code' under IDE Preferences/Debugger/Display Settings.

Another thing that instead doesn't seem to improve anything is changing 'Program Download Options' under Target Settings/Debugger/Debugger Settings.

What's the general feeling of other USB TAP users? is the device suited for debugging projects with large quantities of memory?

Thanks,

Emanuel

[ronco]

There are two possibilities for improving your CodeWarrior debugger's performance: increase the data rate (Interface Clock Frequency) between the USB TAP and your target; and/or decrease the number of data displays in your CodeWarrior IDE while debugging.

To change your USB TAP's Interface Clock Frequency go to Edit->Preferences->Remote Debugging, double-click on the USB TAP entry that you're using then change the Interface Clock Frequency selection to a faster option (refer to the "USB TAP Users Manual" in your CodeWarrior's 'Help' folder for details.)  Bear in mind that different target boards and different processors have different maximum supported Clock Frequencies, and faster data rates are inherently more prone to signal faults.  Your mileage may vary.

To answer your specific questions, No the number of breakpoints does not measurably affect the response time of the debugger.  Once a breakpoint is hit the debugger quickly resolves which breakpoint was hit and returns control to the user.

Having a large number of Expressions displayed in an active data window might visibly affect the response time of the debugger depending on the number and complexity of these expressions.  If reducing the number of these expressions noticeably improves the debugger's performance then consider reducing this number along with reducing the number of data displays if increasing the Interface Clock Frequency does not provide sufficient improvement by itself.

The 'Program Download Options' settings determines which portions of your target code are to be actually downloaded to your board.  Unchecking one or more of these options will speed up the launching of your debugger because less time is spent transmitting data via the USB TAP but you won't get those parts of your code sent to your board.  And once the debugger is up, changing these options has no affect on the debugger's responsiveness.

[ZiglioNZ]

Hi Ronco,

thank you for your detailed reply.

I've never thought of increasing the Interface Clock Freq. and have always had it running at the default 5.120Mhz. But our hardware engineer reckons the max freq allowed by our CPU is 20MHz.

I must say: I had the project on a network drive and moving it to a local drive has improved the debugging process dramatically. 

Since you seem to be the expert, can I ask you also if 'conditional breakpoints' can possibly work while debugging on a target?

Cheers,

Emanuel

Message Edited by ZiglioNZ on 2009-03-25 09:03 AM

[ronco]

Hi Emanuel,

Glad to hear the good news!  I hadn't considered you might be running a networked installation.  I'll have to remember that possibility.

Yes, to answer your follow-up question, yes you may set Conditional Breakpoints.  Details are found in the "Targeting Manual" in your CodeWarrior's /help folder but the overview goes like this:

Conditional Breakpoints, which are defined as valid C expressions, stop the target code only when Breakpoint condition == true.  Examples are

  *((int *) 0x006FFFE4) == 0x0010
  (X == 15) && (Y > Z)
  temperature < Freezing

Condition is entered into the Condition field of the Breakpoint in the 'Breakpoints' panel (View->Breakpoints).

Conditional breakpoints are very handy when trying to capture a specific test point, however the Debugger must halt the target code momentarily every time a conditial breakpoint is hit, evaluate the condition then either resume running target code or halt the target.  This periodic stop/start can greatly slow down the target code, depending on how often the breakpoint occurs.