> If you have a specific reason for why you think the
watchdog reset on
> the LPC is buggy, then please state it.
I looked at one case before, when someone there appears to be a
problem with the watchdog and for which Philips proposed a work
around. I wrote a piece of code to trigger the problem.
It triggered the problem on some variants, but not on my LPC2292 which
leads me to the conclusion this particular problem is specific to only
some variants.
Anotehr other reason is the priority level the watchdog reset appears
to be connected to based on another poster's report that watchdog
reset could be locked out by continually triggering Data Abort exception.
I have suggested and experiment that would confirm or dismiss this
possibility. I supose I could do some experiments to determine one
way or another if this second suspicion is true.
jayasooriah wrote: > --- In l..., Ralph Hempel wrote:
>
>> There may be other ways to get what you want, and it's wise to
>> understand that there is not just one "right" way to get a job
>> like this done :-)
>
> It it not clear to me how you are using the watchdog reset, and why
> you appear to be having difficulty.
Ummm, I'm not having a problem at all. I'm describing one of many
ways to reset a part after a firmware upgrade.
> Your upgrade software should wait till all is done
and then signal the
> host before it initiates a system reset, which I presume you are doing
> using the watchdog timer overflow.
Of course.
> Should the watchdog reset implementation be buggy (I
suspect it is on
> LPC family), so long as one does not make unecessary assumptions about
> the state of the peripherals one should be able to come out of
> watchdog reset just as one would from any other reset.
A watchdog reset should be the same as hardware reset in terms of
the state it leaves the peripherals in. That's why we were discussing
ways in which we could tell the difference between the two.
If you have a specific reason for why you think the watchdog reset on
the LPC is buggy, then please state it.
> It is good defensive programming anyway to make
minimal assumptions.
Yes.
Cheers,
Ralph
Reply by jayasooriah●April 17, 20062006-04-17
--- In l..., Ralph Hempel wrote:
> There may be other ways to get what you want, and
it's wise to
> understand that there is not just one "right" way to get a job
> like this done :-)
It it not clear to me how you are using the watchdog reset, and why
you appear to be having difficulty.
Your upgrade software should wait till all is done and then signal the
host before it initiates a system reset, which I presume you are doing
using the watchdog timer overflow.
Should the watchdog reset implementation be buggy (I suspect it is on
LPC family), so long as one does not make unecessary assumptions about
the state of the peripherals one should be able to come out of
watchdog reset just as one would from any other reset.
It is good defensive programming anyway to make minimal assumptions.
Jaya
Reply by Ralph Hempel●April 17, 20062006-04-17
> How about writing a "magic" value to somewhere in RAM
before you do
> a planned watchdog reset, and then checking it before you zero
> out/load initialised RAM as part of normal startup procedure? I've
> seen this technique used in the past. Obviously you'd need to check
> that the magic value is zeroed out as soon as it's read.
I've used this in the past as well, Brendan, and can vouch for
its usefulness.
We actually had a special segment of RAM that was NOT part of
the BSS, and was preserved through reset. It was checksummed or
CRCed so that random startup values has little chance of being
misinterpreted.
This also allows the buffer to be used for other information that
we might want to preserve through reset. Most runtime libraries
will zero out the entire BSS at reset, so beware!
A soft reset wrote a special value into this buffer, and
then we disabled interrupts and entered a hard loop. The soft
watchdog does the rest. Actually we had a separate hardware
watchdog but that's not really relevant.
There may be other ways to get what you want, and it's wise to
understand that there is not just one "right" way to get a job
like this done :-)
Ralph
Reply by brendanmurphy37●April 17, 20062006-04-17
Eugene,
A soft reset of the CPU is easy enough to arrange. However, what's
less easy to arrange is that each and every peripheral is reset to a
known, correct state with 100% reliability. Although I haven't seen
it on the LPC2000 series, on other MCUs I've seen peripherals get
latched into usless states by attempting a soft reset of the system
(usually invoked when something bad has happened).
In other words, your idea of using the watchdog to do the actual
reset is sound: you're ensured of getting a system in a known
initial state.
How about writing a "magic" value to somewhere in RAM before you do
a planned watchdog reset, and then checking it before you zero
out/load initialised RAM as part of normal startup procedure? I've
seen this technique used in the past. Obviously you'd need to check
that the magic value is zeroed out as soon as it's read.
Brendan
--- In l..., "y3peng" wrote: >
> Hi there,
> The project I am working on requires a software reset after a firmware > upgrade.
>
> One possible solution is to setup a really short watchdog timer.
> However, the firmware design already has a watchdog timer with it, so > it would be harder to distinguish between a real
watchdog reset and
> our intentional reset.
>
> Is there any other ways to cause a software reset in LPC2148?
>
> The problem may also be with our bootloader design because the
> firmware seems to hung when it is started right after being upgraded. > Though it has no issues after a reset.
>
> Thank you for all your help!
>
> Eugene
>
Reply by brendanmurphy37●April 17, 20062006-04-17
--- In l..., "y3peng" wrote: >
> Hi there,
> The project I am working on requires a software reset after a firmware > upgrade.
>
> One possible solution is to setup a really short watchdog timer.
> However, the firmware design already has a watchdog timer with it, so > it would be harder to distinguish between a real
watchdog reset and
> our intentional reset.
>
> Is there any other ways to cause a software reset in LPC2148?
>
> The problem may also be with our bootloader design because the
> firmware seems to hung when it is started right after being upgraded. > Though it has no issues after a reset.
>
> Thank you for all your help!
>
> Eugene
>
Reply by y3peng●April 17, 20062006-04-17
Hi there,
The project I am working on requires a software reset after a firmware
upgrade.
One possible solution is to setup a really short watchdog timer.
However, the firmware design already has a watchdog timer with it, so
it would be harder to distinguish between a real watchdog reset and
our intentional reset.
Is there any other ways to cause a software reset in LPC2148?
The problem may also be with our bootloader design because the
firmware seems to hung when it is started right after being upgraded.
Though it has no issues after a reset.
