Ken,
Thanks for the reference to the previous discussion on this: it's
exactly what I was looking for (confirmation/proof that there is
indeed a problem).
By the way, I think you may have misunderstood my comment on the
interrupt issue. No need to explain where you're coming from: far
from suggesting you change, I'd strongly advise keeping what you
have, if it works and causes no problems. I've seen too many cases
of (inexperienced) engineers tweaking something that works to "make
it more efficient", only to see it explode in people's faces further
down the line. As you point out, there's nothing better then the
knowledge of maybe tens or hundreds of thousands of units in the
field to focus the mind on reliability as THE primary consideration.
It was more for the benefit of others who may be reading to point
out there are much simpler ways of working around the quirks of ARM
interrupts (which also give 100% reliability). Personally, I find
this forum very useful, particularly in the mix of people
contributing, from hobbyists to professionals, each bringing a
particular perspective.
One thing I've learnt is that there is almost never one correct
solution to a problem. In fact, if you can't think of two or three
solutions to a particular problem, you probably don't understand it
well enough in the first place.
My own lesson from this is that I should really have searched the
message archive for watchdog issues before starting.
I think it's a big help too to have Philips actively monitor this
forum: I've no doubt they will react positively to this and other
issues, and provide ammended or new documantation to describe the
various issues with the parts.
Brendan
--- In lpc2000@yahoogroups.com, "Ken Wada" <kwada@a...> wrote:
>
> ok...
> I can surely tell you this...
> I had the Watchdog working perfectly, until I started adding
interrupt
> support, (mainly device drivers for the UART). After days of
pulling
> my hair out, and interpreting the UM for the LPC2214 as a lawyer
would
> do; it occured to me that the UM says 'feed 0x55 then 0xAA' It
made
> absolutely no mentioned about what may happen if the process got
> preempted by an interrupt...
>
> Then alas; when I installed my 1st interrupt service routine; all
> worked fine, for a few hours, and sometimes for a couple of days...
>
> Then my clients started complaining about 'these spurious reset
> events'. They demanded that I fix the problem right away.
>
> SO...
> I came to this forum: AND I saw this:
> message #5470 ---> Please also read all the threads that spawned
from
> this message.
>
> Quickly, I wrappered the WDOG pet thing with my over-engineered
SWI
> service...(to keep any chance of those spurious interrupts thing
from
> happening)
>
> AND...
> It has been working fine now with no glitches for about 9 months
now.
>
> As a side note: from what I can see, you my be able to disable and
> enable interrupts from the main body of your code by writing to
the
> CPSR...
>
> The big problem I have with this is that when you execute the MSR
> instruction...the ARM architecture manual clearly states that
there
> may be a chance of the CPSR contents being copied into the
interrupt
> service CPSR_shadow with both the IRQ and FIQ bits disabled.
>
> You know...the probability of this type of occurence happening, in
a
> real system, is practically nil.
>
> Therefore, I decided to use the more ioctl() style of interfacing
to
> the device drivers using the SWI mechanism... and letting the ARM
> pipeline and state machine sort out all the details... in terms of
> queueing and such.
>
> The counter-side to my over-engineered approach is that it
requires a
> bit more code, and is implemented more like a immutable IOCTL()
device
> driver.
>
> The flipside to this argument, is that the IOCTL() SWI protected
thing
> is pretty much guaranteed to work...
>
> Yes, I know that what I am doing is not elegant, and perhaps a bit
> over-engineered and maybe, in the long run unnecessary....
>
> But, I have been bitten too many times with issues such as this;
> thereforem my cautious approach.
>
> So...you are quite correct Brendan; there really is nothing
> specifically staing the fact that you need to stuff those two WDT
> values back-to-back in the Philips UM.
>
> However, this appears to not be a new issue within this forum. In
> fact, this is how I found out that this is an issue to begin with.
>
> Through this forum!!! There appears to be many other 'real world'
> users out there that have had exactly the same experience as I
have on
> regards to this issue.
>
> Again...about the interrupts...basically I am coding all my
protected
> stuff using the well-known IOCTL() model wrappered within an SWI
> interface...Instead of 'trying' different things...There was
enough
> stated in the ARM reference manual, and the Philips UM that got me
> really paranoid about the whole thing....> so...> I decided that
> caution was the best approach, and took the more circuitous...but
> guarranteed to work approach for affecting the driver interface to
an
> ISR.
>
> By the way; if you look at the Philips interrupt-driven UART ISR,
> (here in this forum, under files); they took exactly the same
approach
> in interfacing the main thread with the UART variables....They
> protected it using an SWI wrapper!!!
>
> If it is good enough for Philips...I guess it probably is good
enough
> for me
>
> Besides; I already understand and know the IOCTL()/SWI model; this
> approach to device drivers is well established and well known.
>
> My 1st exposure to this model came from analyzing all of that
Borland
> MSDOS code that ran on those old x86 machines!
>
> Ken Wada
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendan.murphy@i...
> > wrote:
> >
> >
> > Ken,
> >
> > I'm still curous about your statement "the processor expects
> > a WRITE(0xAA) on the very next cycle". Where is this documented?
It
> > may be true, but if so, I'd say it contradicts the quote I took
from
> > the User Manual (for the LPC213x parts). Or am I misreading what
it
> > says?
> >
> > It's a fairly important point: if the feed has to be done in two
> > adjacent CPU cycles, you're forced to use assembler apart from
> > anything else, in order to do the back-to-back write reliably
(I've
> > checked the assembler o/p from our own code, and it does, but
you
> > can't rely on this: all you need is to change the revision of
the
> > compiler or have a new optimsaition setting and thinmgs can fall
> > apart).
> >
> > On the other point: you're quite right - there's plenty
of "gotchas"
> > with ARM interrupts. It's been a while since I looked at this,
but I
> > seem to recall spending at least a few days armed with a stack
of
> > ARM books/manuals etc. (if you'll forgive the pun) to get our
> > interrupt handling code to a state we were happy with it. Funny
how
> > you forget such things... I think what prompted my question was
the
> > implication that you somehow couldn't set both bits at the same
> > time. As the other response on this points out, you can of
course,
> > and it works, but maybe not in quite the way you'd expect.....
> >
> > I'd apreciate an answer on the watchdog issue though, as it's
very
> > much a live issue with us at the moment.
> >
> > Regards
> > Brendan
> >
> >
> > --- In lpc2000@yahoogroups.com, "Ken Wada" <kwada@a...> wrote:
> > >
> > > --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> > <brendan.murphy@i...
> > > > wrote:
> > > >
> > > >
> > > > Ken,
> > > >
> > > > Can you explain why you think there's a problem with an
> > interrupt
> > > > between the two writes?
> > > >
> > > > According to the User Manual: "Once 0xAA is written to
> > > > the WDFEED register the next operation in the Watchdog
register
> > > space
> > > > should be a WRITE (0x55) to the WDFFED register otherwise
the
> > > > watchdog is triggered."
> > > >
> > > > I take this to mean that the next write to the WDFEED
register
> > has
> > > to
> > > > be 0x55 following the 0xaa: why should it matter if this is
one
> > > cycle
> > > > on, or 1000 cycles on (e.g. to take account of any
interrupt)?
> > I'm
> > > > assuming here that the interrupt itself doesn't go near the
> > > watchdog.
> > > It makes a bit difference! If you WRITE (0x55), the processor
> > expects
> > > a WRITE(0xAA) on the very next cycle. If this is done outside
an
> > > interrupt context, the interrupt service routine will pretty
much
> > > guarantee that this condition is violated!
> > >
> > > >
> > > > Also, for disabling interrupts, why not just disable IRQ and
FIQ
> > in
> > > > the same write to the CPSR? Is there some problem with this?
> > > Yep...huge problem. Actually, you will see this type of
problem
> > with
> > > many processors/especially DSP's with fully pipelined
> > architecture.
> > > The Philips User manual calls this the spurious interrupt
problem.
> > > Actually, Philips basically took their cautionary note
directly
> > from
> > > the ARM users guide.
> > >
> > > Gone are the good-old days of doing something like EA=0, as
per
> > 8051..
> > > .these pipelined architectures are a bit different when it
comes
> > to
> > > instruction processing.
> > >
> > > Fortunately, all of these modern architectures give you a way
to
> > do
> > > these types of operations, (albeit with a bit more effort),
via
> > some
> > > software interrupt (SWI) instruction.
> > >
> > > My 1st encounter with this was with the Intel 80386 chip. This
> > chip
> > > had an instruction pipeline, and I had to use the int86() SWI
> > command
> > > in order to properly code up the atomic sections.
> > >
> > > Ken Wada
> > > >
> > > > regards
> > > > Brendan
> > > >
> > > >
> > > > --- In lpc2000@yahoogroups.com, "Ken Wada" <kwada@a...>
wrote:
> > > > >
> > > > > Basically, your method works fine...
> > > > > UNTIL: you start adding interrupt service routines!
> > > > >
> > > > > This is why:
> > > > > void WDOG_pet()
> > > > > {
> > > > > WDFEED = 0xAA;
> > > > > /* Interrupt occurs here...> dog will NOT pet
> > > > properly!!!
> > > > > ***/
> > > > > WDFEED = 0x55;
> > > > > }
> > > > >
> > > > > /**** example uses Keil compiler directives ***/
> > > > > /********** The following is what I wound up doing, (gotta
> > avoid
> > > > that
> > > > > spurious interrupt issue with the ARM also!!! ***/
> > > > >
> > > > > /**** The actual interface that everybody uses ***/
> > > > > void WDOG_pet (void)
> > > > > {
> > > > > SYSSWI_service (12,0,0,0);
> > > > > }
> > > > >
> > > > > /***** How the SYSSWI_service works, (based on SWI) ***/
> > > > > unsigned SYSSWI_service (SYSSWI opcode, int id, void
*pObj,
> > > > unsigned
> > > > > _user1) __swi(12)
> > > > > {
> > > > > switch (opcode)
> > > > > {
> > > > > case SYSSWI_WDOGPET:
> > > > > SYSSWI_watchDogPet ();
> > > > > break;
> > > > > ...
> > > > > }
> > > > > return (0);
> > > > > }
> > > > >
> > > > > /***** How the SYSSWI_watchDogPet () works ***/
> > > > > static void SYSSWI_watchDogPet (void)
> > > > > {
> > > > > ARM_disableFIQ (); /* make sure FIQ is
> > > > disabled
> > > > > */
> > > > > WDFEED = 0xAA;
> > > > > WDFEED = 0x55;
> > > > > ARM_enableFIQ (); /* re-enable the
> > > > FIQ
> > > > > */
> > > > > }
> > > > >
> > > > > /***** The IRQ is automatically disabled by vectoring to
the
> > SWI..
> > > .
> > > > > however, you need to make the operation atomic with
respect to
> > > FIQ,
> > > > > which is NOT disabled ***/
> > > > >
> > > > > PUBLIC ARM_disableFIQ?A ; interface is ARM mode
> > > > >
> > > > > ARM_disableFIQ?A PROC CODE32
> > > > > MRS R0,CPSR
> > > > > ORR R0,R0,#0x0040 ; Mask just
the
> FIQ
> > > > > MSR CPSR_c,R0
> > > > > BX R14
> > > > >
> > > > > ENDP
> > > > >
> > > > > PUBLIC ARM_enableFIQ?A ; interface is ARM mode
> > > > >
> > > > > ARM_enableFIQ?A PROC CODE32
> > > > > MRS R0,CPSR
> > > > > BIC R0,R0,#0x0040 ; Enable just
the
> > FIQ
> > > > > MSR CPSR_c,R0
> > > > > BX R14
> > > > >
> > > > > ENDP
> > > > > END
> > > > >
> > > > >
> > > > > --- In lpc2000@yahoogroups.com, "Ake Hedman, eurosource"
> > > > <akhe@b...>
> > > > > wrote:
> > > > > >
> > > > > > Hi all.
> > > > > >
> > > > > > I am trying to enable the watchdog but the result is a
total
> > > hang
> > > > of
> > > > > the
> > > > > > board. Not even the bootloader is possible to reach
after
> > the
> > > > crash
> > > > > and
> > > > > > I have to reapply power with P0.14 low to get access to
the
> > > > > botloader
> > > > > > again. Reset is not enough.
> > > > > >
> > > > > > The code to initialize the watchdog is
> > > > > >
> > > > > > // initialize the watchdog timer
> > > > > > WDTC = 0xffffffff; //
> > 15000000; //
> > > One
> > > > > second
> > > > > > = 15000000
> > > > > > WDMOD = WDEN | WDRESET; //
Activate
> > > > watchdog
> > > > > > WDFEED = 0xAA; WDFEED = 0x55;
> > > > > >
> > > > > > I must have misunderstood the WD functionality. What am
I
> > doing
> > > > > wrong?
> > > > > > In the above code the watchdog should not trigger until
5
> > > minutes
> > > > > > elapsed so even if a vector should be wrong the code
that
> > follow
> > > > > should
> > > > > > run for a while but as soon as I write to the WDMOD
register
> > I
> > > > get a
> > > > > hang.
> > > > > >
> > > > > > /Ake
> > > > > >
> > > > > > --
> > > > > > ---
> > > > > > Ake Hedman (YAP - Yet Another Programmer)
> > > > > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > > > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > > > > Company home: http://www.eurosource.se
> > > > > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > > > > Personal homepage: http://www.eurosource.se/akhe
> > > > > > Automated home: http://www.vscp.org
> > > > > >
> > > > >
> > > >
> > >
> >
>Message
Re: Problem with watchdog
2005-12-10 by brendanmurphy37