Lpc2000

I just recently discovered that if your ISP tool (by whomever) fails 
at a higher baud rate it is probably because of three issues:

1. There is an error in the Philips LPC2xxx User Manual.  All 
commands sent to the bootloader do not require a C/R and a L/F; in 
fact only a C/R is required.  

2. If the ISP software validates all returned commands it will fail 
to compare, for instance, "Synchronized[c/r][l/f]OK[c/r][l/f]" which 
it expects after transmitting the command "Synchronized[c/r][l/f]" 
with "Synchronized[c/r]OK[c/r][l/f][l/f]" which it actually 
receives.  Obviously the bootloader sent the "OK[c/r][l/f]" when it 
received the C/R in the "Synchronized[c/r][l/f]" command and then 
received and echoed the L/F later. 

3. Bootloader response behavior in this case is transmit 
latency/inter-byte gap/baud rate dependent.

I do not know if this will be only a V1.63 issue and have sent an 
email to my Philips FAE regarding this whole problem.  I'll let 
everyone know what develops.

--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
> 
> > Hi,
> > 
> > we have production run of boards with LPC2214 and LPC2294, these 
> are 
> > our LPC+external memory header boards and LPC+external 
> > memory+ethernet boards.
> > On about 20% of the boards Philips ISP utility fail to program 
the 
> > code on speed above 19200. Everything seems like baudrate problem 
> as 
> > if 19200 or lower speed is used ISP programs everything just fine.
> 
> 
> I experience this problem quite frequently on my 2114 board (1.63 
> bootloader), especially at 115k baud speeds. Using a 14.7456 Mhz I 
> expected updating to be at least hassle free at high bauds (2114 
> user manual). However, the process tends to halt & fail somewhere 
in 
> the middle. Normally I'd resort to retrying the update until it 
> eventually completes. I'm having the success with 56k baud & below 
> speeds and below, with less halts occuring at 56k. Keep me posted 
if 
> u've found the cause of this problem.
> 
> Leighton