Problem with watchdog
Started by ●December 6, 2005
Reply by ●December 10, 20052005-12-10
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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > >
> > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply by ●December 10, 20052005-12-10
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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > > >
> > > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
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
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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > > >
> > > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
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
Reply by ●December 10, 20052005-12-10
Why Karma ? Use Paypal... :-)
Regards,
Martin
----- Original Message -----
From: "Ake Hedman, eurosource" <akhe@akhe...>
To: <lpc2000@lpc2...>
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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > > >
> > > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
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
Yahoo! Groups Links
Regards,
Martin
----- Original Message -----
From: "Ake Hedman, eurosource" <akhe@akhe...>
To: <lpc2000@lpc2...>
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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > > >
> > > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A >
>
> >. >
>
--
---
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
Yahoo! Groups Links
Reply by ●December 10, 20052005-12-10
;-)
/Ake
Martin Maurer wrote:
> Why Karma ? Use Paypal... :-)
>
> Regards,
>
> Martin
>
> ----- Original Message -----
> From: "Ake Hedman, eurosource" <akhe@akhe...>
> To: <lpc2000@lpc2...>
> 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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > > > >
> > > > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>>
> > Microcontrollers
> >
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>>
> > Pic microcontrollers
> >
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>>
> >
> > 8051 microprocessor
> >
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A>>
> >
> >
> >
> >
> > >.
> >
> >
> >
> > --
> ---
> 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 >
> >. >
>
--
---
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
/Ake
Martin Maurer wrote:
> Why Karma ? Use Paypal... :-)
>
> Regards,
>
> Martin
>
> ----- Original Message -----
> From: "Ake Hedman, eurosource" <akhe@akhe...>
> To: <lpc2000@lpc2...>
> 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@lpc2..., "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@lpc2..., "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@lpc2..., "Ken Wada" <kwada@a...> wrote:
> > > > >
> > > > > --- In lpc2000@lpc2..., "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@lpc2..., "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@lpc2..., "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&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=tsVC-J9hJ5qyXg0WPR0l6g>>
> > Microcontrollers
> >
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=DvJVNqC_pqRTm8Xq01nxwg>>
> > Pic microcontrollers
> >
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=TpkoX4KofDJ7c6LyBvUqVQ>>
> >
> > 8051 microprocessor
> >
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s&.sig=1Ipf1Fjfbd_HVIlekkDP-A>>
> >
> >
> >
> >
> > >.
> >
> >
> >
> > --
> ---
> 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 >
> >. >
>
--
---
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
Reply by ●December 10, 20052005-12-10
OK Guys,
I can confirm that the WD problem is solved in my case. Thanks a lot
all! (Description of solution below.)
I think this definitely should be mentioned in the err data sheets for
the affected processors (or clearly in the UM) as the resulting
symptoms are such that the problem is very hard to debug..
Cheers
/Ake How I solved it:
I have replaced all dog-feeds with
mycpsr = disableIRQ();
WDFEED = 0xAA; WDFEED = 0x55;
restoreIRQ( mycpsr );
where disableIRQ and restoreIRQ is from R O Software
/******************************************************************************
*
* $RCSfile: armVIC.c,v $
* $Revision: 1.1 $
*
* This module provides the interface routines for setting up and
* controlling the various interrupt modes present on the ARM processor.
* Copyright 2004, R O SoftWare
* No guarantees, warrantees, or promises, implied or otherwise.
* May be used for hobby or commercial purposes provided copyright
* notice remains intact.
*
*****************************************************************************/
#include "types.h"
#include "armVIC.h"
#define IRQ_MASK 0x00000080
#define FIQ_MASK 0x00000040
#define INT_MASK (IRQ_MASK | FIQ_MASK)
static inline unsigned __get_cpsr(void)
{
unsigned long retval;
asm volatile (" mrs %0, cpsr" : "=r" (retval) : /* no inputs */ );
return retval;
}
static inline void __set_cpsr(unsigned val)
{
asm volatile (" msr cpsr, %0" : /* no outputs */ : "r" (val) );
}
unsigned disableIRQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr | IRQ_MASK);
return _cpsr;
}
unsigned restoreIRQ(unsigned oldCPSR)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr((_cpsr & ~IRQ_MASK) | (oldCPSR & IRQ_MASK));
return _cpsr;
}
unsigned enableIRQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr & ~IRQ_MASK);
return _cpsr;
}
unsigned disableFIQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr | FIQ_MASK);
return _cpsr;
}
unsigned restoreFIQ(unsigned oldCPSR)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr((_cpsr & ~FIQ_MASK) | (oldCPSR & FIQ_MASK));
return _cpsr;
}
unsigned enableFIQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr & ~FIQ_MASK);
return _cpsr;
}
--
---
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
I can confirm that the WD problem is solved in my case. Thanks a lot
all! (Description of solution below.)
I think this definitely should be mentioned in the err data sheets for
the affected processors (or clearly in the UM) as the resulting
symptoms are such that the problem is very hard to debug..
Cheers
/Ake How I solved it:
I have replaced all dog-feeds with
mycpsr = disableIRQ();
WDFEED = 0xAA; WDFEED = 0x55;
restoreIRQ( mycpsr );
where disableIRQ and restoreIRQ is from R O Software
/******************************************************************************
*
* $RCSfile: armVIC.c,v $
* $Revision: 1.1 $
*
* This module provides the interface routines for setting up and
* controlling the various interrupt modes present on the ARM processor.
* Copyright 2004, R O SoftWare
* No guarantees, warrantees, or promises, implied or otherwise.
* May be used for hobby or commercial purposes provided copyright
* notice remains intact.
*
*****************************************************************************/
#include "types.h"
#include "armVIC.h"
#define IRQ_MASK 0x00000080
#define FIQ_MASK 0x00000040
#define INT_MASK (IRQ_MASK | FIQ_MASK)
static inline unsigned __get_cpsr(void)
{
unsigned long retval;
asm volatile (" mrs %0, cpsr" : "=r" (retval) : /* no inputs */ );
return retval;
}
static inline void __set_cpsr(unsigned val)
{
asm volatile (" msr cpsr, %0" : /* no outputs */ : "r" (val) );
}
unsigned disableIRQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr | IRQ_MASK);
return _cpsr;
}
unsigned restoreIRQ(unsigned oldCPSR)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr((_cpsr & ~IRQ_MASK) | (oldCPSR & IRQ_MASK));
return _cpsr;
}
unsigned enableIRQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr & ~IRQ_MASK);
return _cpsr;
}
unsigned disableFIQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr | FIQ_MASK);
return _cpsr;
}
unsigned restoreFIQ(unsigned oldCPSR)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr((_cpsr & ~FIQ_MASK) | (oldCPSR & FIQ_MASK));
return _cpsr;
}
unsigned enableFIQ(void)
{
unsigned _cpsr;
_cpsr = __get_cpsr();
__set_cpsr(_cpsr & ~FIQ_MASK);
return _cpsr;
}
--
---
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
Reply by ●December 11, 20052005-12-11
Ake Hedman, eurosource wrote:
>OK Guys,
>
>I can confirm that the WD problem is solved in my case. Thanks a lot
>all! (Description of solution below.)
>
>I think this definitely should be mentioned in the err data sheets for
>the affected processors (or clearly in the UM) as the resulting
>symptoms are such that the problem is very hard to debug..
>
>Cheers
>/Ake >How I solved it:
>
>I have replaced all dog-feeds with
>
> mycpsr = disableIRQ();
> WDFEED = 0xAA; WDFEED = 0x55;
> restoreIRQ( mycpsr );
>
>where disableIRQ and restoreIRQ is from R O Software >
I've been following this thread with interest as I expected to use the
watchdog in my application. The old design used a MAX690 where you
would toggle the input to keep the watchdog happy. This worked well for
us as the foreground software would set the pin high and the interrupt
routines would reset it low. This ensured that both sections of the
program were operating okay. Foreground did non-time-critical tasks
while the background serviced realtime critical tasks & communications
over RS485.
I had expected to do something similar with the LPC2000 parts. Feed the
watchdog with 0xaa from the interrupt layer and then feed it with 0x55
from the foreground. It was expected that even if the watchdog received
something like this, it would still be fine:
0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... What value is a watchdog that requires you to carefully feed it, it
sounds as if the watchdog is very fragile? I noticed that Philips
Applications people studiously stayed out of this thread about the
watchdog! I suspect that the watchdog is severly broken and they did
not want to comment on it? Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
>OK Guys,
>
>I can confirm that the WD problem is solved in my case. Thanks a lot
>all! (Description of solution below.)
>
>I think this definitely should be mentioned in the err data sheets for
>the affected processors (or clearly in the UM) as the resulting
>symptoms are such that the problem is very hard to debug..
>
>Cheers
>/Ake >How I solved it:
>
>I have replaced all dog-feeds with
>
> mycpsr = disableIRQ();
> WDFEED = 0xAA; WDFEED = 0x55;
> restoreIRQ( mycpsr );
>
>where disableIRQ and restoreIRQ is from R O Software >
I've been following this thread with interest as I expected to use the
watchdog in my application. The old design used a MAX690 where you
would toggle the input to keep the watchdog happy. This worked well for
us as the foreground software would set the pin high and the interrupt
routines would reset it low. This ensured that both sections of the
program were operating okay. Foreground did non-time-critical tasks
while the background serviced realtime critical tasks & communications
over RS485.
I had expected to do something similar with the LPC2000 parts. Feed the
watchdog with 0xaa from the interrupt layer and then feed it with 0x55
from the foreground. It was expected that even if the watchdog received
something like this, it would still be fine:
0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... What value is a watchdog that requires you to carefully feed it, it
sounds as if the watchdog is very fragile? I noticed that Philips
Applications people studiously stayed out of this thread about the
watchdog! I suspect that the watchdog is severly broken and they did
not want to comment on it? Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
Reply by ●December 11, 20052005-12-11
Tom Walsh wrote:
>
> I've been following this thread with interest as I expected to use the
> watchdog in my application. The old design used a MAX690 where you
> would toggle the input to keep the watchdog happy. This worked well for
> us as the foreground software would set the pin high and the interrupt
> routines would reset it low. This ensured that both sections of the
> program were operating okay. Foreground did non-time-critical tasks
> while the background serviced realtime critical tasks & communications
> over RS485.
>
> I had expected to do something similar with the LPC2000 parts. Feed the
> watchdog with 0xaa from the interrupt layer and then feed it with 0x55
> from the foreground. It was expected that even if the watchdog received
> something like this, it would still be fine:
>
> 0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... > What value is a watchdog that requires you to carefully feed it, it
> sounds as if the watchdog is very fragile? I noticed that Philips
> Applications people studiously stayed out of this thread about the
> watchdog! I suspect that the watchdog is severly broken and they did
> not want to comment on it? > Regards,
>
> TomW
At least I would say that its a bit strange behavior for a watchdog.
Anyway there is a work around and it appears to work well (at least in
my case). I have only noticed this on the LPC2138 part so I don't know
if the same "problem" appears on other silicon. If it is that would have
been nice to now though.
/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
>
> I've been following this thread with interest as I expected to use the
> watchdog in my application. The old design used a MAX690 where you
> would toggle the input to keep the watchdog happy. This worked well for
> us as the foreground software would set the pin high and the interrupt
> routines would reset it low. This ensured that both sections of the
> program were operating okay. Foreground did non-time-critical tasks
> while the background serviced realtime critical tasks & communications
> over RS485.
>
> I had expected to do something similar with the LPC2000 parts. Feed the
> watchdog with 0xaa from the interrupt layer and then feed it with 0x55
> from the foreground. It was expected that even if the watchdog received
> something like this, it would still be fine:
>
> 0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... > What value is a watchdog that requires you to carefully feed it, it
> sounds as if the watchdog is very fragile? I noticed that Philips
> Applications people studiously stayed out of this thread about the
> watchdog! I suspect that the watchdog is severly broken and they did
> not want to comment on it? > Regards,
>
> TomW
At least I would say that its a bit strange behavior for a watchdog.
Anyway there is a work around and it appears to work well (at least in
my case). I have only noticed this on the LPC2138 part so I don't know
if the same "problem" appears on other silicon. If it is that would have
been nice to now though.
/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
Reply by ●December 11, 20052005-12-11
At 01:09 AM 12/11/05 -0500, Tom Walsh wrote:
>I've been following this thread with interest as I expected to use the
>watchdog in my application. The old design used a MAX690 where you
>would toggle the input to keep the watchdog happy. This worked well for
>us as the foreground software would set the pin high and the interrupt
>routines would reset it low. This ensured that both sections of the
>program were operating okay. Foreground did non-time-critical tasks
>while the background serviced realtime critical tasks & communications
>over RS485.
>
>I had expected to do something similar with the LPC2000 parts. Feed the
>watchdog with 0xaa from the interrupt layer and then feed it with 0x55
>from the foreground. It was expected that even if the watchdog received
>something like this, it would still be fine:
>
>0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... >What value is a watchdog that requires you to carefully feed it, it
>sounds as if the watchdog is very fragile?
Actually, that is rather the point. The idea is to prevent being able to
accidentally satisfy the watchdog with writes from multiple places in the
program. Watchdogs are supposed to be somewhat twitchy. Even so an
internal watchdog doesn't usually catch events like loss of
oscillator. The Philips watchdog also appears to allow the trip time to be
reprogrammed during operation which is a big weakness.
BTW this is not an unusual requirement for microcontroller based watchdogs,
at least in my experience.
You may find (if you haven't read it already) Jack Ganssle's article on
watchdogs interesting. http://www.ganssle.com/watchdogs.pdf
>I noticed that Philips
>Applications people studiously stayed out of this thread about the
>watchdog! I suspect that the watchdog is severly broken and they did
>not want to comment on it?
Actually, from these accounts the watchdog is fine. The documentation
needs to be updated though. The line referring the watchdog register space
probably needs to be updated to match the wording used for the PLLFEED
register which explicitly refers to back to back VPB writes being
needed. I expect the two peripherals are using identical logic.
I wouldn't mind that period hole being fixed though, and maybe even seeing
a minimum time between feeds enforced.
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
>I've been following this thread with interest as I expected to use the
>watchdog in my application. The old design used a MAX690 where you
>would toggle the input to keep the watchdog happy. This worked well for
>us as the foreground software would set the pin high and the interrupt
>routines would reset it low. This ensured that both sections of the
>program were operating okay. Foreground did non-time-critical tasks
>while the background serviced realtime critical tasks & communications
>over RS485.
>
>I had expected to do something similar with the LPC2000 parts. Feed the
>watchdog with 0xaa from the interrupt layer and then feed it with 0x55
>from the foreground. It was expected that even if the watchdog received
>something like this, it would still be fine:
>
>0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... >What value is a watchdog that requires you to carefully feed it, it
>sounds as if the watchdog is very fragile?
Actually, that is rather the point. The idea is to prevent being able to
accidentally satisfy the watchdog with writes from multiple places in the
program. Watchdogs are supposed to be somewhat twitchy. Even so an
internal watchdog doesn't usually catch events like loss of
oscillator. The Philips watchdog also appears to allow the trip time to be
reprogrammed during operation which is a big weakness.
BTW this is not an unusual requirement for microcontroller based watchdogs,
at least in my experience.
You may find (if you haven't read it already) Jack Ganssle's article on
watchdogs interesting. http://www.ganssle.com/watchdogs.pdf
>I noticed that Philips
>Applications people studiously stayed out of this thread about the
>watchdog! I suspect that the watchdog is severly broken and they did
>not want to comment on it?
Actually, from these accounts the watchdog is fine. The documentation
needs to be updated though. The line referring the watchdog register space
probably needs to be updated to match the wording used for the PLLFEED
register which explicitly refers to back to back VPB writes being
needed. I expect the two peripherals are using identical logic.
I wouldn't mind that period hole being fixed though, and maybe even seeing
a minimum time between feeds enforced.
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
Reply by ●December 11, 20052005-12-11
--- In lpc2000@lpc2..., Tom Walsh <tom@o...> wrote:
>
> I had expected to do something similar with the LPC2000 parts. Feed
the
> watchdog with 0xaa from the interrupt layer and then feed it with 0x55
> from the foreground. It was expected that even if the watchdog
received
> something like this, it would still be fine:
>
> 0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... > What value is a watchdog that requires you to carefully feed it, it
> sounds as if the watchdog is very fragile? I noticed that Philips
> Applications people studiously stayed out of this thread about the
> watchdog! I suspect that the watchdog is severly broken and they did
> not want to comment on it? > Regards,
>
> TomW
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------
>
It sounds like you have described a really robust watchdog timer!!
It detects and stops fragile software.
It's function is NOT to make life easy for the software developer, it
is to make the system more reliable for the end user by forcing good
software and hardware design. The watchdog kick should always be
cosecutive instructions to reduce the possibility of random events
from kicking the timer.
At least, that was the philosophy of the ASIC teams that I have worked
with.
--Dave
>
> I had expected to do something similar with the LPC2000 parts. Feed
the
> watchdog with 0xaa from the interrupt layer and then feed it with 0x55
> from the foreground. It was expected that even if the watchdog
received
> something like this, it would still be fine:
>
> 0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 .... > What value is a watchdog that requires you to carefully feed it, it
> sounds as if the watchdog is very fragile? I noticed that Philips
> Applications people studiously stayed out of this thread about the
> watchdog! I suspect that the watchdog is severly broken and they did
> not want to comment on it? > Regards,
>
> TomW
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------
>
It sounds like you have described a really robust watchdog timer!!
It detects and stops fragile software.
It's function is NOT to make life easy for the software developer, it
is to make the system more reliable for the end user by forcing good
software and hardware design. The watchdog kick should always be
cosecutive instructions to reduce the possibility of random events
from kicking the timer.
At least, that was the philosophy of the ASIC teams that I have worked
with.
--Dave
Reply by ●December 11, 20052005-12-11
derbaier wrote:
> --- In lpc2000@lpc2..., Tom Walsh <tom@o...> wrote:
> >
> > I had expected to do something similar with the LPC2000 parts. Feed
> the
> > watchdog with 0xaa from the interrupt layer and then feed it with 0x55
> > from the foreground. It was expected that even if the watchdog
> received
> > something like this, it would still be fine:
> >
> > 0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 ....
> >
> >
> > What value is a watchdog that requires you to carefully feed it, it
> > sounds as if the watchdog is very fragile? I noticed that Philips
> > Applications people studiously stayed out of this thread about the
> > watchdog! I suspect that the watchdog is severly broken and they did
> > not want to comment on it?
> >
> >
> > Regards,
> >
> > TomW
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net, http://cyberiansoftware.com
> > "Windows? No thanks, I have work to do..."
> > ----------------
> >
> It sounds like you have described a really robust watchdog timer!!
> It detects and stops fragile software.
>
> It's function is NOT to make life easy for the software developer, it
> is to make the system more reliable for the end user by forcing good
> software and hardware design. The watchdog kick should always be
> cosecutive instructions to reduce the possibility of random events
> from kicking the timer.
>
> At least, that was the philosophy of the ASIC teams that I have worked
> with.
>
> --Dave The absolute majority of watchdogs, internal or external, function by
toggling a bit from time to time. Where in the code you do this
toggling is something you have to investigate for each project. The
common point in any case is that if the program pass a certain point in
the flow we allow the application to live for n milliseconds more.
The 0xAA, 0x55 sequence is nothing else either. It may look safer then
toggling a bit but false watchdog triggers have never been a problem for
an extended time during my years as an embedded developer. The chance
that your crashed program start to toggle a watchdog bit or write a
0xAA, 0x55 sequence is just minimal and in that light I think Tom's
reasoning is fully correct and would not make the watchdogs
functionality less good. At least IMHO.
But requiring the 0xAA,0x55 sequence is acceptable to of course. The
need to mask interrupts while doing it is not. Thats really bad.
/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
> --- In lpc2000@lpc2..., Tom Walsh <tom@o...> wrote:
> >
> > I had expected to do something similar with the LPC2000 parts. Feed
> the
> > watchdog with 0xaa from the interrupt layer and then feed it with 0x55
> > from the foreground. It was expected that even if the watchdog
> received
> > something like this, it would still be fine:
> >
> > 0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 ....
> >
> >
> > What value is a watchdog that requires you to carefully feed it, it
> > sounds as if the watchdog is very fragile? I noticed that Philips
> > Applications people studiously stayed out of this thread about the
> > watchdog! I suspect that the watchdog is severly broken and they did
> > not want to comment on it?
> >
> >
> > Regards,
> >
> > TomW
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net, http://cyberiansoftware.com
> > "Windows? No thanks, I have work to do..."
> > ----------------
> >
> It sounds like you have described a really robust watchdog timer!!
> It detects and stops fragile software.
>
> It's function is NOT to make life easy for the software developer, it
> is to make the system more reliable for the end user by forcing good
> software and hardware design. The watchdog kick should always be
> cosecutive instructions to reduce the possibility of random events
> from kicking the timer.
>
> At least, that was the philosophy of the ASIC teams that I have worked
> with.
>
> --Dave The absolute majority of watchdogs, internal or external, function by
toggling a bit from time to time. Where in the code you do this
toggling is something you have to investigate for each project. The
common point in any case is that if the program pass a certain point in
the flow we allow the application to live for n milliseconds more.
The 0xAA, 0x55 sequence is nothing else either. It may look safer then
toggling a bit but false watchdog triggers have never been a problem for
an extended time during my years as an embedded developer. The chance
that your crashed program start to toggle a watchdog bit or write a
0xAA, 0x55 sequence is just minimal and in that light I think Tom's
reasoning is fully correct and would not make the watchdogs
functionality less good. At least IMHO.
But requiring the 0xAA,0x55 sequence is acceptable to of course. The
need to mask interrupts while doing it is not. Thats really bad.
/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
