Lpc2000

Hi Tim,
I haven't checked this on my own hardware, but it sounds to me like
you have RESET and P0.14 swapped over.
The bootloader can only look at P0.14 after RESET has been released.
So I would expect P0.14 to be asserted (low) for longer than RESET. 

Hope this helps,
Danish
--- In lpc2000@yahoogroups.com, "tah2k" <tah2k@...> wrote:
> I'm currently experiencing a very frustrating issue with the LPC2138 
> bootloader. I can successfully and reliably use the Philips flash 
> utility to download an image to a blank LPC2138 once and only once. 
> After that, the flash utility is never able to communicate with the 
> LPC2138.
> 
> I have been monitoring the recent bootloader thread that was 
> resolved by manipulating the watchdog overflow flag which, if set, 
> will cause the bootloader reques to be ignored. Unfortunately, this 
> is not the same problem I am having because I'm never enabling the 
> watchdog.
> 
> I've been working with an evaluation board for 6 months now so I 
> felt confident I understood the processor because I never had this 
> issue. Now that I am bringing up custom hardware, I removed 
> everything from the board except the processor, JTAG, and power 
> supplies. I thought perhaps my code was inadvertently configuring an 
> I/O pin in conflict, so I modified the application code to simply 
> sit in a loop after disabling interrupts and other basic init steps.
> 
> The signals to the processor are exactly what I would expect:
> 1.) The reset line and P0.14 are pulled low by the Philips Flash 
> application at t=0.
> 2.) The P0.14 line is held low for about 470mS before being 
> released, and the reset is held low for about 820mS before being 
> released.
> 3.) After these transitions, the processor sees the 0x3F being 
> transmitted by the flash utility.
> 
> So, as far as I can tell, everything is ocuring correctly, but I am 
> unable to access the bootloader after the first initial image 
> download. I was initially swapping processors, but each one behaves 
> the same way.