hello everyone,
i am trying to implement with my team a watchdog for an embedded unit.
the processor is ARM pxa-270 and the instruction set is ARMv5TE,
running a debian tweaked distro, and on top a few necessary
applications that we have developed. along with it there is a xiling
control chip for the peripheral devices of the unit.. the watchdog
timer will be running in this chip.

The idea is that the core of these applications will reset the
watchdog counter in frequent intervals, thus giving it 'life' until
the next checkpoint comes along. if the processor fails to reset the
watchdog counter on the control chip (for whatever reason application /
OS crash), i would like a reset to be asserted to the processor, so it
will start from scratch.

for that i tried to read through the instruction set manual, where it
said that during a reset assertion the program counter is reset to
0x0 ... the assembler code that compiled and does that is the
following

.text
.global main
main:
.start:
mov     pc, #0

however, running that produces a seg.fault. i am wondering if there is
a chance the OS is preventing such an executable from running...is it
possible? is there a way to overcome it?
thank you in advance for your help

[ Post a follow-up to this message ]

nass wrote:
> hello everyone,
> i am trying to implement with my team a watchdog for an embedded unit.
> the processor is ARM pxa-270 and the instruction set is ARMv5TE,
> running a debian tweaked distro, and on top a few necessary
> applications that we have developed. along with it there is a xiling
> control chip for the peripheral devices of the unit.. the watchdog
> timer will be running in this chip.
>
> The idea is that the core of these applications will reset the
> watchdog counter in frequent intervals, thus giving it 'life' until
> the next checkpoint comes along. if the processor fails to reset the
> watchdog counter on the control chip (for whatever reason application /
> OS crash), i would like a reset to be asserted to the processor, so it
> will start from scratch.
>
> for that i tried to read through the instruction set manual, where it
> said that during a reset assertion the program counter is reset to
> 0x0 ... the assembler code that compiled and does that is the
> following
>
>         .text
>         .global main
> main:
> .start:
>         mov     pc, #0

Your process runs in unprivileged mode in a virtual address space. Since
address 0 isn't mapped, it segfaults. This is isually to trap null
pointer dereferences.

If you needs a watchdog : Write a kernel driver for it.



Igmar

[ Post a follow-up to this message ]

On Jul 17, 10:47 am, Igmar Palsenberg <ig...@palsenberg.local> wrote:
> nass wrote: 
> 
> 
> 
>
> Your process runs in unprivileged mode in a virtual address space. Since
> address 0 isn't mapped, it segfaults. This is isually to trap null
> pointer dereferences.
>
> If you needs a watchdog : Write a kernel driver for it.
>
>         Igmar

well, to get into perspective. i thought this little code had nothing
to do with memory space.. i'm just 'putting' a constant value in the
program counter, thats a register alright... no? how is connected to
the memory...?

[ Post a follow-up to this message ]

nass wrote:
 
[vbcol=seagreen] 

[vbcol=seagreen]
> well, to get into perspective. i thought this little code had nothing
> to do with memory space.. i'm just 'putting' a constant value in the
> program counter, thats a register alright... no? how is connected to
> the memory...?

It's connected to memory by the simple fact, that the next instruction
is going to be loaded from there ... isn't this the very purpose of
the program counter? So, your process now tries to execute code from
a memory page that isn't even mapped ... what do you expect ... I mean
besides a segfault.

[ Post a follow-up to this message ]

Rainer Temme wrote:
> nass wrote:
> 
> 
>
> 
>
> It's connected to memory by the simple fact, that the next instruction
> is going to be loaded from there ... isn't this the very purpose of
> the program counter? So, your process now tries to execute code from
> a memory page that isn't even mapped ... what do you expect ... I mean
> besides a segfault.

Furthermore, it is extremely likely that RESET does other
things besides just zero the program counter.  It probably
puts the MMU in a known state (e.g., "disabled"), puts the
interrupt mechanisms in a known state (e.g., "disabled"), and
re-frollixes the jimjams.  The exact list of things RESET does
will be found in your processor and/or chipset documentation;
by doing just one of those many things you will not achieve
a RESET.

The act of getting dressed involves donning various
undergarments, a shirt, trousers, shoes, and maybe a hat.
If you climbed out of the bath, put on your shoes, and
walked out into the street, would you be dressed?

--
Eric Sosman
esosman@ieee-dot-org.invalid

[ Post a follow-up to this message ]

nass wrote:

> well, to get into perspective. i thought this little code had nothing
> to do with memory space.. i'm just 'putting' a constant value in the
> program counter, thats a register alright... no?

That's the program counter of the current process. That means you reset
the PC to address 0 in the process' current address space. That
segfauls, since #0 in a process isn't mapped.

> how is connected to
> the memory...?

Because a CPU with a MMU simply doesn't work the way to think it works.



Igmar

[ Post a follow-up to this message ]