;-)
/Ake
Martin Maurer wrote:
> 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
> <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
> <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
> <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
> <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 Links
>
>
>
>
>
>
>
>
>
> 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]