Why Karma ? Use Paypal... :-)
Regards,
Martin
----- Original Message -----
From: "Ake Hedman, eurosource" <akhe@...>
To: <lpc2000@yahoogroups.com>
Sent: Saturday, December 10, 2005 2:22 PM
Subject: Re: [lpc2000] Re: Problem with watchdog
Hi and thankyou for this discussion.
I just want to confirm that my problems also go away when I turn of
IRQ's while feeding the dog. I have just tested it on a minimalistic
sample where I only have I2C and UART interrupts and where the problem
starts as soon as I add the I2C code.
I will try this on my real application and report back.
You are all worth a beer on me tonight (if I only could reach you...).
Lets hope that Karma things works... :-)
/Ake
brendanmurphy37 wrote:
>
> 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
>
>
>
> SPONSORED LINKS
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
> * Visit your group "lpc2000
> <http://groups.yahoo.com/group/lpc2000>" on the web.
>
> * To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>
--
---
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
[Non-text portions of this message have been removed]
Yahoo! Groups LinksMessage
Re: [lpc2000] Re: Problem with watchdog
2005-12-10 by Martin Maurer