Hi Jerry,
The fix will also not expose the accidental introduction of flash writes in the future, it'll just stop those writes from having any effect.
IOW, it simply hides the bug. :-(
Yeah, I didn't like that as a solution either.
It would be nicer to generate an exception if a write to flash occurs during the period before relocation, at least that way the introduction of an accidental flash write would be detected immediately. I could have a look at the 83xx MMU settings during that time and see if there was an alternative solution using that.
Using the MMU that early is going to be some work and has risks of other mysterious lockups when done wrong. MMUs are different for different processors and, often, within different branches of the same family of processors. This will add to the complexity.
MMU == complexity == risk. :-(
Yep, I agree.
The 440EP solution to generate an exception looked a bit nicer, but its not portable either.
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 :)
Pros:
- Get an exception identifying a bad bug occurrence rather than silent
pass (mostly) or failure (mysteriously).
Cons:
- More complexity == risk
- Debug capabilities, like the MMU, are different for different
processors and families. This could be complex and could turn into an ifdefhell.
- It may be easier and better to use a debugger (e.g. BDI-3000) to
control the hardware breakpoint registers. A debugger may get unhappy or may simply undo our doings if we directly control the hardware breakpoint registers.
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.
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