| ??? 12/05/02 22:53 Read: times |
#33865 - RE: infinite loop (oops) |
<html>
(oops ... forgot to login ... pardon my html ...) production notes ... If you are looking to trap an error condition by placing an infinite loop at the end of your program ... it would be better to place the loop at the end of available PROM. And/or fill unused PROM with infinite loops, using a macro. Or jump to a diagnostic routine instead, or to a monitor service routine, so the problem can be debugged further. And/or use a watchdog timer, external or internal. But as someone noted recently, don't enable the watchdog during development/code/debug/unit-test, only during final testing and rollout, this way the processor state will be preserved and you can debug the problem easier. If the processor jumps to an unused address in PROM, it will start executing whatever garbage it finds until something stops it. It IS garbage because it is not the execution thread you planned. If it gets to the end of PROM, it will roll over to address 0x0000 and execute your boot routine. If your boot routine assumes a hardware reset has been performed, it may (unwisely) assume a machine state that is not true, i.e., power-on defaults for all '51 settings, or power-on conditions for the circuit/machine external to the chip. If you are lucky, the garbage opcodes will cause no ill effect. Unlucky, the processor could perform unwanted actions, or return to an actual execution thread but with corrupt data. I don't remember what the 8051 will do if it hits an illegal opcode (I think there is only one unused opcode in the standard '51 instruction set). Probably it just skips it. (1750A processors generate a machine interrupt, in this event.) <table><tr><td>james</td><td> </td><td>www.jameshinnant.com</td></tr></table> </html> |
