Lpc2000

For a good while now, I've been programming new lpc2114s with the 
Philips ISP Flash utility without problems. 

Until renctly, I just received an lpc2114 unit that only works 
partially with the ISP Utility. 

Only a few commands work OK:
- Read Part ID & Boot Loader ID (version reads 1.64)
- Blank check (Device/sectors) (returns device/selected sectors 
blank)

However, attempting to program the chip doesn't work:
- Upload to Flash
- Erase (Device/Sectors)
both commands return Cmmunication Errors at first instance

I'm interesting to know if anyone came across this problem. I'm not 
sure if either there's a way around it or I'm dealing with a faulty 
chip (bad bootloader).

thanks,
Leighton

--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
>
> For a good while now, I've been programming new lpc2114s with the 
> Philips ISP Flash utility without problems. 
> 
> Until renctly, I just received an lpc2114 unit that only works 
> partially with the ISP Utility. 
> 
> Only a few commands work OK:
> - Read Part ID & Boot Loader ID (version reads 1.64)
> - Blank check (Device/sectors) (returns device/selected sectors 
> blank)
> 
> However, attempting to program the chip doesn't work:
> - Upload to Flash
> - Erase (Device/Sectors)
> both commands return Cmmunication Errors at first instance
> 
> I'm interesting to know if anyone came across this problem. I'm not 
> sure if either there's a way around it or I'm dealing with a faulty 
> chip (bad bootloader).
> 
> thanks,
> Leighton
>
Hi,
 I know this is far stretch but I had similar problem with another 
LPC2000 chip and diference was in RS232 chips . STMicro ( MAX3232 
equivalent ) was not the same as MAXIM or TI equivalent. The same 
syndrom - ISP would not download code - otherwise all serial 
communications were OK.
 Radim.

Hi,

Have you tried talking to the device over a serial terminal program 
like "HyperTerminal" or "TeraTerm"  instead of using the ISP utility. 
You can start by issuing a "?" and then the part would return 
with "Synchronized"...then would follow the ISP procedure. I think 
this flow is mentioned in the UM.

By doing this you can get a more detailed picture of why ISP is 
failing. If a ISP command fails/succeeds the bootloader always 
returns a "code".

Using the code, you can get more information from the part regarding 
this problem.

Amit

--- In lpc2000@yahoogroups.com, "radim100" <radim100@y...> wrote:
>
> --- In lpc2000@yahoogroups.com, "Leighton Rowe" 
<leightonsrowe@y...> 
> wrote:
> >
> > For a good while now, I've been programming new lpc2114s with the 
> > Philips ISP Flash utility without problems. 
> > 
> > Until renctly, I just received an lpc2114 unit that only works 
> > partially with the ISP Utility. 
> > 
> > Only a few commands work OK:
> > - Read Part ID & Boot Loader ID (version reads 1.64)
> > - Blank check (Device/sectors) (returns device/selected sectors 
> > blank)
> > 
> > However, attempting to program the chip doesn't work:
> > - Upload to Flash
> > - Erase (Device/Sectors)
> > both commands return Cmmunication Errors at first instance
> > 
> > I'm interesting to know if anyone came across this problem. I'm 
not 
> > sure if either there's a way around it or I'm dealing with a 
faulty 

> > chip (bad bootloader).
> > 
> > thanks,
> > Leighton
> >
> Hi,
>  I know this is far stretch but I had similar problem with another 
> LPC2000 chip and diference was in RS232 chips . STMicro ( MAX3232 
> equivalent ) was not the same as MAXIM or TI equivalent. The same 
> syndrom - ISP would not download code - otherwise all serial 
> communications were OK.
>  Radim.
>

Hi Leighton

>
> For a good while now, I've been programming new lpc2114s with the 
> Philips ISP Flash utility without problems. 
> 
> Until renctly, I just received an lpc2114 unit that only works 
> partially with the ISP Utility. 

It is almost certainly the hardware. Check the signal on the RX 
line - if it has overshoot or ringing then there will be problems 
(maybe the capacitors on the RS232 transceiver are bad?).

An initial design of mine used a high speed gate in the Rx line 
(TinyLogic) between RS232 transceiver and RX pin. I could establish 
communication but downloads would always fail - in my case somewhere 
in the middle. The fast TinyLogic had spikes at the output 
(overshoot) - once I removed this device I never had problems again.

There are number of posting in the archives about the receiver being 
sensitive to this and most people with problems (if not all) found 
it to be due to signal problems on this line and could solve it 
accordingly.

Regards

Mark Butcher
www.mjbc.ch

> Have you tried talking to the device over a serial terminal 
program 
> like "HyperTerminal" or "TeraTerm"  instead of using the ISP 
utility. 
> You can start by issuing a "?" and then the part would return 
> with "Synchronized"...then would follow the ISP procedure. I think 
> this flow is mentioned in the UM.
> By doing this you can get a more detailed picture of why ISP is 
> failing. If a ISP command fails/succeeds the bootloader always 
> returns a "code".
> Using the code, you can get more information from the part 
regarding 
> this problem.

I've been using the Bray++ Terminal.
http://bray.velenje.cx/avr/terminal/
This comes with DSR/RTS control buttons (Hyterterminal doesn't have 
this) which I need to run my my board correctly. 

The synchronising sequence works, but however I haven't yet figured 
out all the replies for the basic commands:
-Read Part ID (J<CR><LF>) returns a 0x00 but no part ID bytes
-Read BootPart ID (K<CR><LF>) returns an unknown string

>  I know this is far stretch but I had similar problem with another 
> LPC2000 chip and diference was in RS232 chips . STMicro ( MAX3232 
> equivalent ) was not the same as MAXIM or TI equivalent. The same 
> syndrom - ISP would not download code - otherwise all serial 
> communications were OK.

I'm using a MAX3314 rs232 chip to drive both lines.

> It is almost certainly the hardware. Check the signal on the RX 
> line - if it has overshoot or ringing then there will be problems 
> (maybe the capacitors on the RS232 transceiver are bad?).
> 
> An initial design of mine used a high speed gate in the Rx line 
> (TinyLogic) between RS232 transceiver and RX pin. I could 
establish 
> communication but downloads would always fail - in my case 
somewhere 
> in the middle. The fast TinyLogic had spikes at the output 
> (overshoot) - once I removed this device I never had problems 
again.

It very well could be a hardware problem. Both RX/TX signals look 
pretty good to me (clean square wave with no spikes or anything). 
However I notice a -0.1 V to 6V on the T1OUT line, which seems a 
little trivial to me.

Thanks for the replies guys, I think I might be getting closer.

Leighton

Hey Amit,

Thanks for your suggestion on using the hyperterminal to test run 
the on-chip bootloader. I ran a set of basic commands on two boards 
(one good board vs the bad board) and logged the communicated bytes 
as seperate files (below). You might be able to understand this.

NB. all lines proceeded with (comments) represents replies by the 
lpc. Other lines were sent by the PC. Here it is!

Terminal log file -  Good Board
Date: 11/2/2005 - 1:47:27 PM
-----------------------------------------------
Synchronized		(received ? character)
Synchronized
OK			(board officially synchronized)
P 2 3
0			(prepared sector 2&3)
U 23130
0			(unlocked erase/write command)
E 2 3
0			(erase successful)
J
0			(part ID read successful)
16908050		(ID#)

-----------------------------------------------
Date: 11/2/2005 - 1:51:38 PM
End log file

Terminal log file - Bad Board
Date: 11/2/2005 - 1:40:00 PM
-----------------------------------------------
Synchronized		(received 1st character)
Synchronized
OK			(board officially synchronized)
P 2 3
0			(prepared sectors 2&3)
U 23130
0			(unlocked write/erase cmds)
E 2 3
	       <------	(No Code Returned)
-----------------------------------------------
Date: 11/2/2005 - 1:45:40 PM
End log file

I notice that the lpc chip hangs after I send the erase command, and 
fails responding to any future comands sent by the PC.

This probably verifies my suspicion that the chip giving problems 
might have a corrupt bootloader. Otherwise I don't know how to get 
around this problem. Let me know what you think.

Leighton

--- In lpc2000@yahoogroups.com, "Amit" <emailakb@y...> wrote:
>
> Hi,
> 
> Have you tried talking to the device over a serial terminal 
program 
> like "HyperTerminal" or "TeraTerm"  instead of using the ISP 
utility. 
> You can start by issuing a "?" and then the part would return 
> with "Synchronized"...then would follow the ISP procedure. I think 
> this flow is mentioned in the UM.
> 
> By doing this you can get a more detailed picture of why ISP is 
> failing. If a ISP command fails/succeeds the bootloader always 
> returns a "code".
> 
> Using the code, you can get more information from the part 
regarding 

> this problem.
> 
> Amit