Protection for erratic program jump

[Chibouraska]

Hi,

I want to fill unused program memory with a goto command in case
the program jumps to a random place in program memory where nothing
exist and this goto could trigger a reset. Is this good practice and how could i implement this in code. Thanks.

AC
-------------------------------

[asmboy]

have you ever encountered a random jump such as you fear ??

also

what about BYTE alignment ??

a GOTO is a MULTIBYTE instruction &&
how do you know you would even land on the right start byte ???

can i tell you that you are afraid of something that is pretty unlikely
and frankly if you are so fearful of errant code that you wrote
then read up on the watchdog function.

[PCM programmer]

Here are some previous threads on the subject of filling unused rom:
http://www.ccsinfo.com/forum/viewtopic.php?t=42658
http://www.ccsinfo.com/forum/viewtopic.php?t=30969
http://www.ccsinfo.com/forum/viewtopic.php?t=46905

[Chibouraska]

Thanks PCM i will look up on these links. I read in a book from Jack Ganssle
that this could be something to consider, but you are right AsmBoy the WDT
is especially the windowed version on the PIC24F but my MCU PIC24FJ128GA010 doesn't have the windowed version too bad. But if really
this could happen that a MCU could just jump like that i think the internal WDT wont be any good then an external WDT could be the best solution.

[asmboy]

Corrupted user ram is a far more likely possibility-
and that usually stems from a boo boo in using arrays / strings etc
courtesy of no index checking in run time (unless you add it )

The most likely source of program code going walkabout
is a core compiler problem or some inappropriate GOTO or inline assembler
that is programmer initiated. In general due to Harvard Arch, its far less likely with PIC than other MCU families, IMHO......

[SherpaDoug]

I recently read an article, possibly by Ganssle, that warned that smaller memory geometries of newer chips will inevitably lead to more random cosmic ray induced memory faults. I remember a figure like 1 bit every 4 months per GB of memory. As a result the article claimed programmers must stop assuming their RAM is infallible and make sure programs can recover from random faults with check sums, watchdogs, etc.

Fortunately our PICs don't have GBs of RAM and they don't use the smallest memory cells so these random faults will be less common for us. But it is a real problem and it will only get worse with time.

The last time I looked into unprogrammed ROM issues I found that such ROM usually decodes to a NO OP instruction. So if the PC were corrupted and the PIC jumped to unprogrammed ROM it would run through the NO OPs until it hit some valid code.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[gpsmikey]

For what it's worth, for our embedded software that had to meet FAA regulations, we did a number of things - the unused FLASH memory was filled with one byte restart instructions. One of the background tasks that had to complete on time calculated the CRC of the various tasks stored in FLASH and compared that to the stored expected value. If any of those failed, it did a restart - if it failed on power-up to pass the validation checks, the processor was sent into a tight loop that did nothing. You also want to consider clearing the WDT at the end of the calculations for memory sanity etc, not triggering the reset from an interrupt (many people have done that only to discover that the WDT was getting reset as expected, but the rest of the program had crashed for some reason - the WDT needs to get reset when all checks pass, not at regular intervals (it should be set to a time somewhat greater than the length of time required to do all the sanity checks in the background). You can start the checks from an interrupt, but make sure it does all the checks before it can reset the WDT. (in our case, it was the 68332 processor, but this applies to whatever processor you are using in general).

Forgot to mention - in our case, any failures were logged to fault memory before the restart happened so we could look later and see if/when there had been issues. FAA gets fussy about things that are flight critical :-)

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3