Lpc2000

--- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@i...
> wrote:
>
> 
> Ken,
> 
> Can you explain why you think there's a problem with an interrupt 
> between the two writes?
> 
> According to the User Manual: "Once 0xAA is written to
> the WDFEED register the next operation in the Watchdog register 
space 
> should be a WRITE (0x55) to the WDFFED register otherwise the 
> watchdog is triggered."
> 
> I take this to mean that the next write to the WDFEED register has 
to 
> be 0x55 following the 0xaa: why should it matter if this is one 
cycle 
> on, or 1000 cycles on (e.g. to take account of any interrupt)? I'm 
> assuming here that the interrupt itself doesn't go near the 
watchdog.
It makes a bit difference! If you WRITE (0x55), the processor expects 
a WRITE(0xAA) on  the very next cycle. If this is done outside an 
interrupt context, the interrupt service routine will pretty much 
guarantee that this condition is violated!

> 
> Also, for disabling interrupts, why not just disable IRQ and FIQ in 
> the same write to the CPSR? Is there some problem with this?
Yep...huge problem. Actually, you will see this type of problem with 
many processors/especially DSP's with fully pipelined architecture. 
The Philips User manual calls this the spurious interrupt problem. 
Actually, Philips basically took their cautionary note directly from 
the ARM users guide.

Gone are the good-old days of doing something like EA=0, as per 8051..
.these pipelined architectures are a bit different when it comes to 
instruction processing.

Fortunately, all of these modern architectures give you a way to do 
these types of operations, (albeit with a bit more effort), via some 
software interrupt (SWI) instruction.

My 1st encounter with this was with the Intel 80386 chip. This chip 
had an instruction pipeline, and I had to use the int86() SWI command 
in order to properly code up the atomic sections.

Ken Wada
> 
> regards
> Brendan
>  
> 
> --- In lpc2000@yahoogroups.com, "Ken Wada" <kwada@a...> wrote:
> >
> > Basically, your method works fine...
> > UNTIL: you start adding interrupt service routines!
> > 
> > This is why:
> > void WDOG_pet()
> > {
> > WDFEED = 0xAA;
> > /*             Interrupt occurs here...> dog will NOT pet 
> properly!!! 
> > ***/
> > WDFEED = 0x55;
> > }
> > 
> > /**** example uses Keil compiler directives ***/
> > /********** The following is what I wound up doing, (gotta avoid 
> that 
> > spurious interrupt issue with the ARM also!!! ***/
> > 
> > /**** The actual interface that everybody uses ***/
> > void WDOG_pet (void)
> > {
> >     SYSSWI_service (12,0,0,0);
> > }
> > 
> > /***** How the SYSSWI_service works, (based on SWI) ***/
> > unsigned SYSSWI_service (SYSSWI opcode, int id, void *pObj, 
> unsigned 
> > _user1) __swi(12)
> > {
> >     switch (opcode)
> >     {
> >       case SYSSWI_WDOGPET:
> >         SYSSWI_watchDogPet ();
> >         break;
> >       ...
> >     }
> >     return (0);
> > }
> > 
> > /***** How the SYSSWI_watchDogPet () works ***/
> > static void SYSSWI_watchDogPet (void)
> > {
> >     ARM_disableFIQ ();                /* make sure FIQ is 
> disabled     
> >      */
> >     WDFEED  = 0xAA;
> >     WDFEED  = 0x55;
> >     ARM_enableFIQ ();                 /* re-enable the 
> FIQ             
> >      */
> > }
> > 
> > /***** The IRQ is automatically disabled by vectoring to the SWI..
.
> > however, you need to make the operation atomic with respect to 
FIQ, 
> > which is NOT disabled ***/
> > 
> > PUBLIC  ARM_disableFIQ?A ; interface is ARM mode
> > 
> > ARM_disableFIQ?A  PROC  CODE32
> >       MRS   R0,CPSR
> >       ORR   R0,R0,#0x0040                   ; Mask just the FIQ
> >       MSR   CPSR_c,R0
> >       BX    R14
> > 
> >       ENDP
> > 
> > PUBLIC  ARM_enableFIQ?A ; interface is ARM mode
> > 
> > ARM_enableFIQ?A  PROC  CODE32
> >       MRS   R0,CPSR
> >       BIC   R0,R0,#0x0040                   ; Enable just the FIQ
> >       MSR   CPSR_c,R0
> >       BX    R14
> > 
> >       ENDP
> > END
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "Ake Hedman, eurosource" 
> <akhe@b...> 
> > wrote:
> > >
> > > Hi all.
> > > 
> > > I am trying to enable the watchdog but the result is a total 
hang 
> of 
> > the 
> > > board. Not even the bootloader is possible to reach after the 
> crash 
> > and 
> > > I have to reapply power with P0.14 low to get access to the 
> > botloader 
> > > again. Reset is not enough.
> > > 
> > > The code to initialize the watchdog is
> > > 
> > >     // initialize the watchdog timer
> > >     WDTC = 0xffffffff; // 15000000;                        // 
One 
> > second 
> > > = 15000000
> > >     WDMOD = WDEN | WDRESET;                    // Activate 
> watchdog
> > >     WDFEED = 0xAA; WDFEED = 0x55;
> > > 
> > > I must have misunderstood the WD functionality. What am I doing 
> > wrong? 
> > > In the above code the watchdog should not trigger until 5 
minutes 
> > > elapsed so even if a vector should be wrong the code that follow 
> > should 
> > > run for a while but as soon as I write to the WDMOD register I 
> get a 
> > hang.
> > > 
> > > /Ake
> > > 
> > > -- 
> > >  ---
> > > Ake Hedman (YAP - Yet Another Programmer)
> > > eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> > > Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> > > Company home: http://www.eurosource.se      
> > > Kryddor/Te/Kaffe: http://www.brattberg.com
> > > Personal homepage: http://www.eurosource.se/akhe
> > > Automated home: http://www.vscp.org
> > >
> >
>