Codewarrior debugger useless for tracking down my bug

[jrmymllr]

I'm using CW 10.1 on a MCF52259 custom board and P&E Multilink Universal and I have a bug that is driving me nuts.  I cannot track it down to a specific line, because the line of code that apparently causes it changes depending on what I comment out.  Also, the region that "appears" to cause it looks quite benign.

In addition, it only occurs once after a CPU reset.  If I enable WDT, which is cleared in Timer 1, the only interrupt I'm using, the WDT will reset the device.  If WDT is disabled, the chip locks up. 

If I try to pause the debugger when it's in this state, I get an Error box that says "Target request failed: Failed to stop all threads in the process".  Unfortunately this is a huge problem as I can't see the state of anything after the lockup.

This is a very simple program.  There's no OS, and the only form of input are 4 pushbuttons.  I suspect the issue lies with a alphanumeric LCD service function which is called in the Timer 1 interrupt, but I've used this code before. 

Any advice on tracking something like this down?  Specifically, I find it odd, but not unheard of, that it kills the debugger.

[J2MEJediMaster]

Without looking at the source code, all anyone can do is speculate. Here are mine.

1) If you comment out the call to the LCD driver, do things (including the interrupt) work? If so, the culrpit is the LCD driver.

2) Are you feeding the watchdog? The LCD driver might be taking a long time to execute, and the dog bites.

3) Does increasing the size of the stack help? Check that you're doing the proper housekeeping for the stack in your interrupt routine, and that the LCD driver isn't doing things to the stack behind your back.

---Tom

[jrmymllr]

I have did all the basic troubleshooting steps, including disabling the WDT (it's definately not the WDT).  I have increased the size of the stack well beyond where it should be required, as I have lots of free RAM.  I've commented out sections of code in the hope of finding the bad part.

The main issue is the debugger goes south leaving me with no state information.  Here's a question:  what has to occur on the chip to crash the debugger? This might give me a clue as to what part of memory is getting overwritten.

[J2MEJediMaster]

The debugger requires the processor to be in a useable state in order to function. The right kind of bug can hose the processor so that the debugger does not work. Things that can do in short order are:

-- Watchdog exceptiopn fires - you've checked this.

-- Unimplemented interrupt fires and there's no handler. Processor goes out into thw weeds.

-- Stack get trashed so that the processor goes out into the weeds, taking the debugger with it -- Point of increasing the stack size was to spot a memory leak. If things ran longer with a bigger stack, it would be a memory leak. The stack can still be trashed by an interrupt routine or function that munges the return address.

-- Bus error, usually due to data memory alignment. If you are moving words to the LCD, is the buffer word-aligned?

---Tom