Hey,

Thanks Spehro. Your mail is very informative.

So, everything said in this thread. What would be the recommended way
for doing a soft reset? Something that similar to a power cycle would
be the best.

There was one suggestion of putting the program into a loop and
waiting for a watchdog timeout. Though our watchdog timer is quite
long. So maybe reconfiguring it to a millisecond, looping, restoring
to sane value?

What other options are there?

Quintin Beukes



On Mon, Sep 28, 2009 at 7:19 PM, Spehro Pefhany <speff@interlog.com> wrote:
> At 05:03 AM 27/09/2009, you wrote:
>>William "Chops" Westfield wrote:
>> > On Sep 26, 2009, at 12:39 PM, Quintin Beukes wrote:
>> >
>> >> The problem can be reproduced, however, by finish reading from the
>> >> serial interface, then later one doing an exit(0). After doing that a
>> >> few times all serial comms in the future are messed up.
>> >
>> > So you are undoubtably running into the differences between doing a
>> > "real" reset and the partial re-start that happens (perhaps) when you
>> > do exit(0). =A0 A "real" reset will return most of the peripherals to a
>> > default state, as well as restarting the program. A "software reset"
>> > might ONLY return the program to its start address,
>>
>>Now, I do not remember what device this is, but executing the RESET
>>instruction on a PIC18 (or one of the later PIC16 that has that
>>instruction) is doing all register initializations that a hard
>>reset does. What we do not know is if the exit(0) realy executes
>>a real RESET instruction. If it could, depending on the device...
>>--
>
> MPSIM is a really good (and free) tool for figuring out what the compiler
> and (in this case) the start-up code are up to.
>
> MCC18 sets up the stack pointer, does the usual C initialization
> such as clearing static variables, and then has a flow like this:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // initialization is comp=
lete at this point
> loop:
> __init(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 // despite the name, by default thi=
s calls a
> null function.
> =A0 main(); =A0 =A0 =A0 =A0 =A0 =A0 =A0 // call the user main function
> =A0 goto loop;
>
>
> As you can see, it behaves nothing like a RESET when you execute an
> exit(0)-- nothing at all is re-initialized. To the extent exit() is
> defined on a freestanding system (without a "host" or operating system),
> it is supposed to call atexit-registered functions, flush buffers and clo=
se
> streams, then return from main();
>
> Calling exit() more than once is specifically indicated to cause undefined
> behavior in the ANSI/ISO C99 standard.
>
> I don't see any obvious and appropriate applications for exit() in a prog=
ram
> that runs on this kind of system.
>
> Best regards,
>
> Spehro Pefhany --"it's the network..." =A0 =A0 =A0 =A0 =A0 =A0"The Journe=
y is the reward"
> speff@interlog.com =A0 =A0 =A0 =A0 =A0 =A0 Info for manufacturers: http:/=
/www.trexon.com
> Embedded software/hardware/analog =A0Info for designers: =A0http://www.sp=
eff.com
>
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist