Searching \ for '[PIC]: Fill Unused Memory with GOTO xxxx' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=memory
Search entire site for: 'Fill Unused Memory with GOTO xxxx'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Fill Unused Memory with GOTO xxxx'
2002\12\08@140547 by Brooke Clarke

flavicon
face
Hello:

I am having problems that may be caused by jumping into the memory area after my
code ends.  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?

Do I need to be concerned with PCLATH with a 12F675 ( 1 k program memory space)?

Thanks,

Brooke Clarke

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@160505 by David Duffy

flavicon
face
Brooke wrote:
>I am having problems that may be caused by jumping into the memory area
>after my
>code ends.  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?

Fix the code that's causing the jump, don't try to work around it. Use the
time to look
at the code and see where it could be going of the rails. Tables with no
range testing
(or restriction) jumping way too far ahead is probably the most common
cause. Have
a look for missing return statements of the end of subroutines and that
sort of thing.
Is the code written in assembler? You aren't just letting the code wander
off into La La
land at the end are you? If the code truly does "end", you'll have to put a
loop in there
to actually stop it executing code. Like this:

code_start:                     ;start of program
        ...
        do_something            ;do whatever you need
        ...
loop:                           ;all done now so
        goto    loop            ;code stops here

David...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@162759 by Stef

flavicon
face
David Duffy wrote:

> Brooke wrote:
>
>> I am having problems that may be caused by jumping into the memory area
>> after my
>> code ends.  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?
>
>
> Fix the code that's causing the jump, don't try to work around it. Use
> the
> time to look
> at the code and see where it could be going of the rails.

I agree, fix the code first.

But still there's a good reason to fill unused memory with a predefined GOTO statement.
When due to a some reason (strong EM-field, Rö, or whatsoever) the PIC should come into a unused memory array it will be guided to a position where
 1. control can gained again
 2. detection of disturbance can be done.
This is a common technic in designing finit statemachines.
I'm surprised that this method isn't used anymore these days (not seen it for more then 10 years ago).
So it's still on my wishlist to implement this in my programmer.

Stef Mientki

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@170708 by Spehro Pefhany

picon face
At 10:26 PM 12/8/02 +0100, you wrote:


>But still there's a good reason to fill unused memory with a predefined
>GOTO statement.
>When due to a some reason (strong EM-field, Rö, or whatsoever) the PIC
>should come into a unused memory array it will be guided to a position where
>  1. control can gained again
>  2. detection of disturbance can be done.
>This is a common technic in designing finit statemachines.
>I'm surprised that this method isn't used anymore these days (not seen it
>for more then 10 years ago).
>So it's still on my wishlist to implement this in my programmer.

It's a standard precaution.. but the PIC has only only the exact PC size to
address the internal ROM, and the hardware stack wraps as well, so even
if you jump into a whole bunch of  addlw instructions (the unprogrammed
default of all 1's) then it should wrap around and do a cold start
within a very short period of time. It's much more critical with
microprocessors and certain other microcontrollers that have
von Neumann architectures, lack interrupt on invalid address, etc.

If your programmer is putting random crap, or worse, the remains of
previously used programs, in there, then it should be changed!

BTW, an "interesting" feature of the new method of doing OSCCAL
in F676 and some other processors is that if the memory is erased
and an appropriate instruction isn't programmed into the top of
memory, the PIC will appear to be dead- it will call 0x3FF or
whatever, find an instruction that isn't a RETLW, wrap around to
your cold start routine and thus rinse and repeat, ad infinitum.
The programmer is supposed to take care of this detail, of course, but
a lot of the unofficial programmers seem to be somewhat buggy by times.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@172202 by Josh Koffman

flavicon
face
But if you are worried about the PIC losing its way, wouldn't a watchdog
timer be an alternate answer? Wouldn't it be possible to insert the
extra goto's using a pre or post processor on the asm or hex file?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams


Stef wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@175113 by Spehro Pefhany

picon face
At 05:50 PM 12/8/02 -0600, you wrote:
>But if you are worried about the PIC losing its way, wouldn't a watchdog
>timer be an alternate answer? Wouldn't it be possible to insert the
>extra goto's using a pre or post processor on the asm or hex file?

If unknown crap is programmed in there, it could hold a loop that
has a clrwdt instruction in it. You should control the state of all
the program memory for such applications, especially safety-critical
ones.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@175126 by Stef

flavicon
face
Spehro Pefhany wrote:

{Quote hidden}

True, but you cann't detect an error occured !
Stef Mientki

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\08@183055 by Spehro Pefhany

picon face
At 11:49 PM 12/8/02 +0100, you wrote:
>True, but you cann't detect an error occured !
>Stef Mientki

Yes, arguably that's the right way to handle things in production
units, with some kind of logging during the testing process.

You can put use various tricks to detect WDT resets or wrap-arounds
for test purposes. For most embedded applications, the "blue screen
of death" type of handling of exceptions is anathema.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\12\09@105913 by Olin Lathrop

face picon face
> 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


2002\12\09@123540 by Dennis J. Murray

flavicon
face
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 removed}

2002\12\09@144239 by Andrew Warren

flavicon
face
Olin Lathrop <.....PICLISTKILLspamspam.....mitvma.mit.edu> wrote:

> > 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.

Olin, et al:

In MPASM, put this line at the end of your program to fill the dead
space with "GOTO xxxx" instructions:

   FILL (GOTO xxxx), 0x400 - $    ; This assumes a device with
                                  ; 1K of code space.

-Andy

=== Andrew Warren -- EraseMEaiwspam_OUTspamTakeThisOuTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
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


2002\12\09@161009 by Olin Lathrop

face picon face
> In MPASM, put this line at the end of your program to fill the dead
> space with "GOTO xxxx" instructions:
>
>     FILL (GOTO xxxx), 0x400 - $    ; This assumes a device with
>                                    ; 1K of code space.

That would generate a variable number of instruction to be resolved at
link time - something I didn't think the linker knew how to do.  Then
there's the issue of what if the module containing this code doesn't get
located last.  Are you using absolute mode perhaps?


*****************************************************************
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


2002\12\09@171635 by Bob Ammerman

picon face
Indeed he must be Olin.

I knew there was something the linker couldn't do... :-)

Bob Ammerman
RAm Systems

{Original Message removed}

2002\12\09@173333 by Andrew Warren

flavicon
face
Olin Lathrop <PICLISTspamspam_OUTmitvma.mit.edu> wrote:

> >     FILL (GOTO xxxx), 0x400 - $    ; This assumes a device with
> >                                   ; 1K of code space.
>
> That would generate a variable number of instruction to be resolved
> at link time - something I didn't think the linker knew how to do.
> Then there's the issue of what if the module containing this code
> doesn't get located last.

   Good point; I don't know whether the linker can handle this.

   You do have control over the link order, though, don't you?  You
   wouldn't need MUCH control; just enough to ensure that a module
   containing just one "FILL" line was located last.

> Are you using absolute mode perhaps?

   Of course.

   -Andy

=== Andrew Warren -- @spam@aiwKILLspamspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
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


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...