Olin has a good point about the post process, but I have a more basic question: What are we really buying here? If something OUTSIDE the program's control can cause it to take a flying leap, who says that leap will put it into UNUSED memory?? If the real code took up half of available memory, wouldn't you have a 50/50 chance of dropping smack into the middle of your code instead of unused memory?? Talk about unpredictable behaviour!! If you insist on this need, why not just ORG to the last location in program memory & put yout GOTO there?? Don't most program burners leave unused memory erased (i.e. all "1"s)?? I know mine does. Depending on your architecture, that could translate to either XORLW (12Cxx) or ADDLW (16Fxx) instruction (if I'm not mistaken) which, in this case, COULD be harmless - that is, unless you need to preserve the states of the W & FLAG registers. The result of this would be that your code could take a flying leap into unknown territory and continuously execute either XOR or ADD instructions until hitting the GOTO, which would drop you into the error-handling routine. I know what you're trying to do is a common technique on mini- and mainframes, which have specific interrrupts for this kind of thing. If you MUST have reliability, you might want to consider running 3 units in sync and using a polling scheme (minimum 2 processors determine actions). Not Computer101, but not complex either. I, for one, would be interested in your final solution and why you chose it. Good luck! Dennis ----- Original Message ----- From: "Olin Lathrop" To: Sent: Monday, December 09, 2002 10:55 AM Subject: Re: [PIC]: Fill Unused Memory with GOTO xxxx > > Is there a way in MPASM to fill the memory space between my program > > end and the end of physical memory with GOTO xxxx so that the program > will goto > > an error trapping routine when this happens? > > You can fill a specific number of instructions, but I don't think there is > a way to fill all remaining space automatically. It would be really easy > to post process the HEX file to do this however. > > > Do I need to be concerned with PCLATH with a 12F675 ( 1 k program memory > space)? > > Not for GOTOs and CALLs. PCLATH still matters when modifying PCL > directly. > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics