|
Home > Archive > Unix Programming > July 2007 > how to order a low level reset to the system
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to order a low level reset to the system
|
|
|
| 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
| |
| Igmar Palsenberg 2007-07-17, 7:21 am |
| 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
| |
|
| 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...?
| |
| Rainer Temme 2007-07-17, 7:21 am |
| 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.
| |
| Eric Sosman 2007-07-17, 7:21 am |
| 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
| |
| Igmar Palsenberg 2007-07-17, 1:21 pm |
| 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
|
|
|
|
|