I did something like this on a PPC-based product years ago.
That was for an MPC860-based product. I don't know if the trick still works, but I'll describe it here in case it does.
The CPU had a "debug" module with control registers for breakpoints and so on. These registers could be controlled by a software debug module to enable single-step and breakpoint support. The same registers were also controlled by the debug pod, if connected.
Now if the debug pod was connected, some of these registers became "read only" to the CPU.
So on startup, the code could try to modify one of these registers. If it succeeded it knew it was a "production unit" and set itself up accordingly. If it found a debug pod was connected, then it could "break" to the debugger when required (and did some other stuff differently too).
The neatest trick was that when running in "production mode" it programmed the Data Breakpoint registers to trap *ALL* read and write accesses below 64k. That caught all "null-pointer bugs". The memory map had 64k of the interrupt vectors, then "nothing", then the code, then read-only variables, then the stack, then read-write and bss and then free RAM. A second data breakpout was set for writes to all addresses beneath the stack frame. That caught all writes to "read only data", any attempted writes to the code space and also caught stack overflows.
When the debugger was connected it programmed the data breakpoints the same way. Having all those checks on all units everywhere caught a lot of intermittent bugs.
Of course when any of those traps triggered, the breakpoint service routine recorded the complete register set and stack frame for later analysis (it ended up in a file in the file system after the next reboot). So we could debug "stack underrun crashes" from customer sites on the other side of the planet.
Tom
