Debugger gets lost

[lpcware]

Content originally posted in LPCWare by jdurand on Wed Sep 18 17:49:18 MST 2013
I've been using LPCXpresso for quite some time now on a number of projects and it's been working well.  Until now.

I've been writing code for an LPC1113FDB48/302 part for about a month now, debugging has been going fine.  Starting today, when I start stepping into the program, if I step over a routine that accesses the SPI port the disassembly window says "no context" or displays a RAM address and the Debug thread goes away. 

If I run the processor with the debugger connected but not in debug mode, it runs fine.

I've rebooted the computer, restarted LPCXpresso several times.

I just tried setting a break point well past the SPI access and it got there just fine and seems willing to step, so I can continue my debugging.

I'm stumped.

Potentially useful info:
Board of my design (I've designed hundreds of boards, there's no power or noise issues on this), VDD 3.292V (measured).
The SWD pins are not used for anything else, they're connected directly to a header about 1/4" away.
I've been testing the SPI and I2C ports for the past month with no problems. SPI clock = 4.8MHz.
Crystal is 12MHz, default SystemCoreClock of 48MHz.
Using FreeRTOS (I use that in pretty much everything).
LPCXpresso v5.2.4 [Build 2122] [2013-04-29]
Ubuntu Release 12.04 (precise) 32-bit
Kernel Linux 3.2.0-53-generic-pae
GNOME 3.4.2
Memory: 1.9 GiB
Processor: Genuine Intel® CPU 2160 @ 1.80GHz × 2
Available disk space: 200.7 GiB

[lpcware]

Content originally posted in LPCWare by jdurand on Fri Sep 20 09:25:52 MST 2013
Thanks, THAT makes sense.  LPCxpresso debugging (with Red Probe +) has been working so well for so long I didn't even think of that. 

I now remember filing a bug report for another brand of processor that had really serious problems on one specific low-end processor with interrupts. It was nearly impossible to debut at all with interrupts enabled no matter how much stack you had.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Sep 19 09:00:00 MST 2013
When debugging, no interrupts are serviced. When you step over a function, interrupts will be enabled before the code runs. I can imagine a situation where several nested interrupts are now being serviced, each using its own space on the stack.

If you have insufficient stack, you could overflow into the heap, causing corruption. If this is the case, your code has this problem, and it is just that you haven't stressed the system enough (i.e. got a large number of nested interrupts) to have seen it (yet).

[lpcware]

Content originally posted in LPCWare by jdurand on Thu Sep 19 07:03:33 MST 2013
But why does it ONLY get trashed when I step over it?  If I run past it everything is fine.

Note this is code I debugged already, it's been working fine on this board for a month.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Sep 18 23:58:46 MST 2013
The debugger will only report what it sees.

The current source location will be worked out from the PC. If the PC is garbage, then so will the debugger source locations
The Stack trace is based on the SP. If the SP is garbage... You get the picture.

So, it sounds like something is trashing the PC and SP. This is most likely the stack being trashed in one of your functions and the function return is popping trash from the stack.

[lpcware]

Content originally posted in LPCWare by jdurand on Wed Sep 18 17:52:26 MST 2013
Can't edit a thread starter...

Clarification:  Once the debugger is lost, I have to exit and restart, nothing else works.  What I did is I restarted the debugger, set a breakpoint well into my code, and then hit run.  I did NOT try stepping over the SPI part.