Data to fill into unused program space on ARM7.

>> Sometimes Bad Things happen that are outside of the control of the
>> firmware. An ionizing radiation event that flips a bit or a bunch, for
>> example.
>
>That's what watchdogs are for.  Playing tricks with the contents of 
>unused code space is neither necessary, nor particularly likely to help 
>with that.
>

I went to an excellent seminar with Jack Ganssle. He mentioned an example
of a deep space probe, that emptyed the fuel supply because of this.
I don't know about the quality of that particular program, but I assume
that NASA does a bit (pardon the pun) to have good quality.
The reason that I do this is just as much because I am making a system
FLASH checksum, that I verify every now and then. This requires that the
entire FLASH contents are defined. I might just as well define something
useful in stead of NOP. 
I do consider my code as clean and very defensive, and I have yet to see
this happen (or better: I won't!). It might not even catch such an event,
since I only have 4Meg FLASH. This is tiny with regards to the processors
total address space of 4Gig, but I am being as precautous as possible. 
If it works, (I'm still sidetracked) I might ask the HW developer to pull
the data pins to 0xEFFF, so that any external access to undefined address
space will get caught.

Best regards
    Michael

On Mon, 02 Jun 2008 22:29:35 +0200, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>Rich Webb wrote:
>
>> Sometimes Bad Things happen that are outside of the control of the
>> firmware. An ionizing radiation event that flips a bit or a bunch, for
>> example.
>
>That's what watchdogs are for.  Playing tricks with the contents of 
>unused code space is neither necessary, nor particularly likely to help 
>with that.

While watchdog timers are definitively usable in a high radiation
environment, but the last rime I have used watchdog timers was during
the Cold War, when a malfunction in some launching systems might have
quite devastating consequences :-) i.e. startin WW III.

Paul
 

On Jun 2, 12:10 pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Mon, 2 Jun 2008 09:46:49 -0700 (PDT), Ed Prochak
>
> <edproc...@gmail.com> wrote:
> >Don't let your programs run out of control. then you can leave unused
> >space unused.
> >Really, this seems like a kludge to cover over poor program
> >development. Having decent programs will give you bigger payback than
> >this scheme.
>
> Sometimes Bad Things happen that are outside of the control of the
> firmware. An ionizing radiation event that flips a bit or a bunch, for
> example.
>
> --
> Rich Webb     Norfolk, VA

If you are in a rad-hard environment, packing empty space with illegal
instructions will do little or nothing to save your application. (And
while I have not had to program in a rad-hard environment, I'll bet
you haven't either.)  Error detecting and correcting memory and rad-
hard devices will do a lot more to help in this case than loading
DEADDEAD opcodes.

Fact is, the probability of programming errors far out swamps the
probability of memory bit failures due to radiation. Get the code
working robustly and you won't care what is stored in the unused
memory space. This memory packing scheme is a kludge, pure and simple.

  Ed

On Jun 3, 1:45 am, "DanishGuy" <m...@linak.com> wrote:
> >> Sometimes Bad Things happen that are outside of the control of the
> >> firmware. An ionizing radiation event that flips a bit or a bunch, for
> >> example.
>
> >That's what watchdogs are for.  Playing tricks with the contents of
> >unused code space is neither necessary, nor particularly likely to help
> >with that.
>
> I went to an excellent seminar with Jack Ganssle. He mentioned an example
> of a deep space probe, that emptyed the fuel supply because of this.
> I don't know about the quality of that particular program, but I assume
> that NASA does a bit (pardon the pun) to have good quality.
> The reason that I do this is just as much because I am making a system
> FLASH checksum, that I verify every now and then. This requires that the
> entire FLASH contents are defined. I might just as well define something
> useful in stead of NOP.
> I do consider my code as clean and very defensive, and I have yet to see
> this happen (or better: I won't!). It might not even catch such an event,
> since I only have 4Meg FLASH. This is tiny with regards to the processors
> total address space of 4Gig, but I am being as precautous as possible.
> If it works, (I'm still sidetracked) I might ask the HW developer to pull
> the data pins to 0xEFFF, so that any external access to undefined address
> space will get caught.
>
> Best regards
>     Michael

so the question is: is your device going into a deep space probe? or a
nuclear power plant?

 If not, I think you are spending a lot of time on something with very
little payback. It is good to be somewhat paranoid, but this might be
somewhere over the edge. Spending some time doing a failure analysis
of the code would give more benefit. IMHO.

But it does sound like you do decent engineering of the code, just
don't be so paranoid. 8^)

  Ed

On Tue, 3 Jun 2008 05:39:42 -0700 (PDT), Ed Prochak
<edprochak@gmail.com> wrote:

>
>so the question is: is your device going into a deep space probe? or a
>nuclear power plant?
>
> If not, I think you are spending a lot of time on something with very
>little payback. It is good to be somewhat paranoid, but this might be
>somewhere over the edge. Spending some time doing a failure analysis
>of the code would give more benefit. IMHO.

Orbits above 1000 km are quite problematic due to the van Allen
radiation belts.

Below that, make sure that your product doesn't make spurious resets.

For NPPs (Nuclear Power Plant), if the device is going to be used for
extended period of times in places, where high radiation resistance is
required, use radiation hardened components. Apart from that, if the
human can take it, so can the electronics. The DRAM alpha radiation
thing should not be an issue these days.

Paul

>so the question is: is your device going into a deep space probe? or a
>nuclear power plant?
>
> If not, I think you are spending a lot of time on something with very
>little payback. 

It doesn't go into any of the above, but it controls a ring main unit. I
could kill the power to a block or ten.

I'm not spending a lot of time on this... that's what I have you guys for
:o) No, seriously; I had to define something, it might as well be remotely
useful, and I'll learn something in the process. Like posting a question in
a discussion group, that's a first for me :o)

Best regards 
    Michael

>Rich Webb wrote:
>
>> Sometimes Bad Things happen that are outside of the control of the
>> firmware. An ionizing radiation event that flips a bit or a bunch, for
>> example.
>
>That's what watchdogs are for.  Playing tricks with the contents of 
>unused code space is neither necessary, nor particularly likely to help 
>with that.
>
What about the time between when the flipping of the bits happens and the
watchdog resetting the microcontroller?

On Tue, 3 Jun 2008 05:39:42 -0700 (PDT), Ed Prochak
<edprochak@gmail.com> wrote:

>On Jun 3, 1:45 am, "DanishGuy" <m...@linak.com> wrote:
>> >> Sometimes Bad Things happen that are outside of the control of the
>> >> firmware. An ionizing radiation event that flips a bit or a bunch, for
>> >> example.
>>
>> >That's what watchdogs are for.  Playing tricks with the contents of
>> >unused code space is neither necessary, nor particularly likely to help
>> >with that.
>>
>> I went to an excellent seminar with Jack Ganssle. He mentioned an example
>> of a deep space probe, that emptyed the fuel supply because of this.
>> I don't know about the quality of that particular program, but I assume
>> that NASA does a bit (pardon the pun) to have good quality.
>> The reason that I do this is just as much because I am making a system
>> FLASH checksum, that I verify every now and then. This requires that the
>> entire FLASH contents are defined. I might just as well define something
>> useful in stead of NOP.
>> I do consider my code as clean and very defensive, and I have yet to see
>> this happen (or better: I won't!). It might not even catch such an event,
>> since I only have 4Meg FLASH. This is tiny with regards to the processors
>> total address space of 4Gig, but I am being as precautous as possible.
>> If it works, (I'm still sidetracked) I might ask the HW developer to pull
>> the data pins to 0xEFFF, so that any external access to undefined address
>> space will get caught.
>>
>> Best regards
>>     Michael
>
>so the question is: is your device going into a deep space probe? or a
>nuclear power plant?
>
> If not, I think you are spending a lot of time on something with very
>little payback. It is good to be somewhat paranoid, but this might be
>somewhere over the edge. Spending some time doing a failure analysis
>of the code would give more benefit. IMHO.
>
>But it does sound like you do decent engineering of the code, just
>don't be so paranoid. 8^)
>
>  Ed

Good engineers are ALWAYS paranoid. 

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

BWallace wrote:

> What about the time between when the flipping of the bits happens and the
> watchdog resetting the microcontroller?

If anything bad can happen during that time, the dog was insufficiently 
watchful to begin with.  I.e. it's time-out period was too long.

On Thu, 05 Jun 2008 22:08:58 +0200, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>BWallace wrote:
>
>> What about the time between when the flipping of the bits happens and the
>> watchdog resetting the microcontroller?
>
>If anything bad can happen during that time, the dog was insufficiently 
>watchful to begin with.  I.e. it's time-out period was too long.

What makes you think that the bits being flipped will necessarily
result in the WDT *ever* being reset, let alone that it would be
limited to the time-out period? 
Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com