David Hawkins wrote:
Hi Jerry,
[snip]
Most processors available today have debug registers. If the processor used on a given target has a debug register set and the registers can be set to trigger on a write to a range, that would give you an exception. You would not necessarily have to handle the exception "properly", simply enter a spin loop so that the processor stops in a known state with enough information to identify the root cause.
Haven't seen that type of register on the MPC8349EA, it might exist, I just didn't look :)
"e300 Power Architecture Core Family Reference Manual, Rev. 2" Chapter 10 "Debug Features" Section 10.1.3 "Data Address Breakpoint Registers (DABR, DABR2)"
Unfortunately, it looks like it only handles exact address matches, not a range.
The e500 core appears to be able to do ranges. Unfortunately, this is of limited value since it is an unusual capability. (Chapter "8.4 Book E Debug Events" section 8.4.2.4 "Data Address Compare (DAC) Mode")
[snip]
Yep, a repeatable bug can be traced using a debugger. The hard part is making the bug repeatable.
It would be nice to have a technique to trap these pre-relocation bugs. They don't happen often, but they *do* happen and they are hard to find (until they bite you and then they are hard to identify).
What are the capabilities of your debugger? Can you set a hardware breakpoint range on your flash and have it trigger on start up? If so, we should add it to our FAQ and add the technique to our toolbox.
Its a BDI2000.
I don't recall seeing a trap on range feature.
Nope, looks like it is beyond the capability of the e300 core. The BDI hardware breakpoints are just playing with the core's debug registers, so it isn't going to do any better than the core (and the software breakpoints require software assist, so they don't work when running in flash).
This is a tricky one to put in the FAQ, as it really shouldn't happen :)
We managed to get pretty far with the debugger; we eventually found the address at which things died, however, the debugger wasn't able to give us an explanation. It was the logic analyzer on the flash/local-bus that showed the reason. So perhaps thats something that can be added to the FAQ. Let me know if you want something coherent, and I can write a 'logic analyzer tricks and tips' section for the FAQ.
Cheers, Dave
One really good trick is how to hook a logic analyzer to those itty-bitty balls on the processor. Back when I was a boy, processors had 40 legs and no balls. :-D You must have a board with a logic analyzer connector.
Thanks, gvb