Data to fill into unused program space on ARM7.

Greetings.

I'm trying to find some genious data to fill into the unused FLASH spac in my project, so that a stray program counter would get caught and m system would reset. I'm thinking one of multiple solutions:

:o) Loop to current position and get caught by the watchdog

:o) Jump to reset vector

:o) An illegal opcode, that will generate an interrupt

:o) A software interrupt instruction

One problem with most of the solutions is that I'm using ARM and THUM instructions. A THUMB jump to the reset vector might mean something else i ARM. The best solution would be to find some data that is illegal in bot ARM and THUMB. If for instance 0xDEAD is illegal for THUMB, and 0xDEADDEA is illegal for ARM, them my problem would be solved.

Does anybody have a suggestion?

Best regards Michael

Reply to
DanishGuy
Loading thread data ...

Fill it with NOP instructions.

Meindert

Reply to
Meindert Sprang

1) Is NOP the same for ARM and THUMB? 2) How would that catch the error? The processor would just run to the end of flash and execute whatever th HW returns when no device is being addressed.

I would like the processor to reset so that further potentially harmfu execution of un-intended instructions is stopped.

Best regards Michael

Reply to
DanishGuy

Looking at the ARM manual, the pattern 0xEFFF might work. In Thumb mode, it's an undefined instruction (BLX with the LSB=1). In 32-bit mode, it's a software interrupt (SWI #0xFFEFFF). Either one ought to land the processor in an ISR and you can recover from there. I haven't actually tried this. :)

--
   Wim Lewis , Seattle, WA, USA. PGP keyID 27F772C1
Reply to
Wim Lewis

Op Fri, 30 May 2008 12:33:05 +0200 schreef DanishGuy :

I'm assuming ARMv4T here.

All Thumb instructions start with a 4..7 bit opcode identifier; all ARM instructions start with a 4-bit condition code. In ARM mode, you have to use the "always"-code because the CC-bits are unknown (and no CC is illegal in principle). The "always"-code is 0xE, which in Thumb means the unconditional branch (B).

You can use this to make a NOP (branch to next instruction). The encoding for this NOP is 0xE000. In ARM mode, this means AND, MUL, STRH or an illegal sequence. Then it is straightforward to find a 32-bit sequence that will trigger an illegal opcode exception in all cases.

You can also use the unconditional branch to make a single-instruction loop. The encoding for this is 0xE7FF. In ARM mode, this means LDRB or an illegal sequence. So there is no pattern for this option.

You can also use the unconditional branch to jump back one instruction. But that would still give you an LDRB in ARM.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

Thank you very much for your suggestions! I've been sidetracked a bit by some urgent matter, so I havn't been abl to test it yet. I'll come back with the results when I have tested you suggestions. Best regards Michael

Reply to
DanishGuy

Thank you very much for your suggestions! I've been sidetracked a bit by some urgent matter, so I havn't been abl to test it yet. I'll come back with the results when I have tested you suggestions. Best regards Michael

Reply to
DanishGuy

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

Reply to
Ed Prochak

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
Reply to
Rich Webb

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.

Reply to
Hans-Bernhard Bröker

I went to an excellent seminar with Jack Ganssle. He mentioned an exampl 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 assum 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 syste FLASH checksum, that I verify every now and then. This requires that th entire FLASH contents are defined. I might just as well define somethin useful in stead of NOP. I do consider my code as clean and very defensive, and I have yet to se 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 processor 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 pul the data pins to 0xEFFF, so that any external access to undefined addres space will get caught.

Best regards Michael

Reply to
DanishGuy

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

Reply to
Paul Keinanen

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 to
Ed Prochak

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 to
Ed Prochak

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 to
Paul Keinanen

It doesn't go into any of the above, but it controls a ring main unit. 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 fo :o) No, seriously; I had to define something, it might as well be remotel useful, and I'll learn something in the process. Like posting a question i a discussion group, that's a first for me :o)

Best regards Michael

Reply to
DanishGuy

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

Reply to
BWallace

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
 Click to see the full signature
Reply to
Spehro Pefhany

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 to
Hans-Bernhard Bröker

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
 Click to see the full signature
Reply to
Spehro Pefhany

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.