Reply by DanishGuy June 23, 20082008-06-23
Hi

Finally got back from my side tracking, and took a look at the 0xEFFF
solution, and just as you said, Wim, in THUMB mode it went straight to the
invalid-opcode-interrupt and in ARM mode it triggered a SWI.
That was the solution to my problem (if you can call it that).
Thanks a lot Wim.

Best regards
    Michael
Reply by Spehro Pefhany June 6, 20082008-06-06
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
Reply by June 5, 20082008-06-05
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.
Reply by Spehro Pefhany June 5, 20082008-06-05
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
Reply by BWallace June 5, 20082008-06-05
>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?
Reply by DanishGuy June 4, 20082008-06-04
>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
Reply by Paul Keinanen June 3, 20082008-06-03
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
Reply by Ed Prochak June 3, 20082008-06-03
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
Reply by Ed Prochak June 3, 20082008-06-03
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
Reply by Paul Keinanen June 3, 20082008-06-03
On Mon, 02 Jun 2008 22:29:35 +0200, Hans-Bernhard Br&#4294967295;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