Lpc2000

I don't understand very well what is it that you want me to test. By 
clearing the watchdog flags my problem went away.

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> I am looking at what appears to be a different manifestation of the 
problem 
> you encountered in that power cycling is required to recover form a 
lockup 
> in order to transfer control to ISP by pulling P0.14 low.
> 
> Philips explains this happens can if "timeout value is too small".  
The 
> user manual seems to say writing anything less than 0xff will 
result in 
> minimum timeout of PCLK x 256 x 4.
> 
> The test code below then should create the lockup scenario, but it 
does not 
> on my 2292.  I cannot see where I got it wrong.
> 
> Can you try this on your board please?
> 
> Thanks.
> 
> Jaya
> 
> GNU Source:
> 
> >@ 
======================================================================
> >@ Interrupt Vectors
> >
> >         .code   32
> >
> >         @ entry points vector
> >start:
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >
> >         .ltorg
> >
> >@ End of Interrupt Vectors
> >@ 
======================================================================
> >
> >
> >@ 
======================================================================
> >@ Error Scenario
> >
> >         .code   32
> >
> >error:
> >         @ force reset
> >         ldr     r0, =WATCH_DOG
> >         mov     r1, #3
> >         str     r1, [r0, #0]
> >         str     r1, [r0, #4]    @ WDTC = 3
> >         mov     r1, #0xaa
> >         str     r1, [r0, #8]    @ WDFEED = 0xaa
> >         mov     r1, #0x55
> >         str     r1, [r0, #8]    @ WDFEED = 0x55
> >         b       .
> >
> >@ End Error Scenario
> >@ 
======================================================================
> 
> HEX Binary: (vectors not check-sum patched)
> 
> >:1000000018F09FE514F09FE510F09FE50CF09FE5D8
> >:1000100008F09FE504F09FE500F09FE504F01FE580
> >:10002000240000000E02A0E30310A0E3001080E50E
> >:10003000041080E5AA10A0E3081080E55510A0E3A5
> >:08004000081080E5FEFFFFEA55
> >:00000001FF
> 
> 
> >Message: 17
> >    Date: Thu, 23 Feb 2006 12:30:37 -0000
> >    From: "Guillermo Prandi" <yahoo.messenger@...>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >Hi, Jayasooriah. Indeed the watchdog is the problem. At this stage 
of
> >development I am only using the watchdog to provide a software 
reset
> >function. Apparently this behavior is triggering only after using
> >this function. And yes, you are right; the bit should be cleared by
> >the external reset.
> >
> >It looks like this behavior is 'by design' so there is no other
> >workaround than switching off the unit.
> >
> >Guille
> 
> 
> >Message: 8
> >    Date: Thu, 23 Feb 2006 23:28:38 -0000
> >    From: "philips_apps" <philips_apps@...>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >The bootloader does not look at the RISR register. It looks at the
> >WDTOF flag in WDMOD register.
> >Even clearing of watchdog flag in user application may not help (if
> >timeout is too small) because the bootloader runs before 
application.
> 
> 
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>