Data to fill into unused program space on ARM7.

Started by DanishGuy May 30, 2008
Greetings.

I'm trying to find some genious data to fill into the unused FLASH space
in my project, so that a stray program counter would get caught and my
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 THUMB
instructions. A THUMB jump to the reset vector might mean something else in
ARM. The best solution would be to find some data that is illegal in both
ARM and THUMB. If for instance 0xDEAD is illegal for THUMB, and 0xDEADDEAD
is illegal for ARM, them my problem would be solved.

Does anybody have a suggestion?

Best regards
   Michael


"DanishGuy" <mij@linak.com> wrote in message
news:hoCdnYM27N58SqLVnZ2dnUVZ_uqdnZ2d@giganews.com...
> Greetings. > > I'm trying to find some genious data to fill into the unused FLASH space > in my project, so that a stray program counter would get caught and my > 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
Fill it with NOP instructions. Meindert
>Fill it with NOP instructions.
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 the HW returns when no device is being addressed. I would like the processor to reset so that further potentially harmful execution of un-intended instructions is stopped. Best regards Michael
In article <hoCdnYM27N58SqLVnZ2dnUVZ_uqdnZ2d@giganews.com>,
DanishGuy <mij@linak.com> wrote:
>One problem with most of the solutions is that I'm using ARM and THUMB >instructions. A THUMB jump to the reset vector might mean something else in >ARM. The best solution would be to find some data that is illegal in both >ARM and THUMB. If for instance 0xDEAD is illegal for THUMB, and 0xDEADDEAD >is illegal for ARM, them my problem would be solved. > >Does anybody have a suggestion?
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 <wiml@hhhh.org>, Seattle, WA, USA. PGP keyID 27F772C1
Op Fri, 30 May 2008 12:33:05 +0200 schreef DanishGuy <mij@linak.com>:
> Greetings. > > I'm trying to find some genious data to fill into the unused FLASH space > in my project, so that a stray program counter would get caught and my > 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 THUMB > instructions. A THUMB jump to the reset vector might mean something else > in > ARM. The best solution would be to find some data that is illegal in both > ARM and THUMB. If for instance 0xDEAD is illegal for THUMB, and > 0xDEADDEAD > is illegal for ARM, them my problem would be solved. > > Does anybody have a suggestion?
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/
Thank you very much for your suggestions!
I've been sidetracked a bit by some urgent matter, so I havn't been able
to test it yet. I'll come back with the results when I have tested your
suggestions.
Best regards
    Michael
Thank you very much for your suggestions!
I've been sidetracked a bit by some urgent matter, so I havn't been able
to test it yet. I'll come back with the results when I have tested your
suggestions.
Best regards
    Michael
On May 30, 6:33 am, "DanishGuy" <m...@linak.com> wrote:
> Greetings. > > I'm trying to find some genious data to fill into the unused FLASH space > in my project, so that a stray program counter would get caught and my > 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 THUMB > instructions. A THUMB jump to the reset vector might mean something else in > ARM. The best solution would be to find some data that is illegal in both > ARM and THUMB. If for instance 0xDEAD is illegal for THUMB, and 0xDEADDEAD > is illegal for ARM, them my problem would be solved. > > Does anybody have a suggestion? > > Best regards > Michael
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
On Mon, 2 Jun 2008 09:46:49 -0700 (PDT), Ed Prochak
<edprochak@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
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.